Slashdot Mirror
Firefox and IE Still Not Getting Along
juct writes "Heise describes a new demo showing how Firefox running under Windows XP SP2 can be abused to start applications. For this to work, however, Internet Explorer 7 needs to be installed. This severe security problem promises another round in the 'who-is-to-blame-war' between Mozilla and Microsoft. Mozilla currently is leading the race for a patch, as they have one ready in their bugzilla database. 'The authors of the demo note that there are many further examples of such vulnerabilities via registered URIs. What is so far visible is just "the tip of the iceberg". They state that registered URIs are tantamount to a remote gateway into your computer. To be on the safe side, users should, in the authors' opinion, deregister all unnecessary URIs - without, however, elucidating which are superfluous.'"
Mozilla is leading the race to a patch as they have a PATCH in their bugzilla database.
They are leading the race for a patch. They have one (PATCH) ready in their database.
It's a simple matter of complex programming.
If you're a Windows Vista user, you don't really have a choice. It comes pre-installed if you want it or not.
Just about any application can forward malicious data to IE7. Microsoft can blame Firefox all they want but the hole will still exist in IE7 after having been patched by the Mozilla org. I repeat, the hole is accessible from any application connecting to the internet, not just firefox. IE6 does not have this security issue so its safe to assume the fault lies with Microsoft. Last time when the roles was the other way around, when Firefox passed malicious things onto IE Microsoft said the receiving application was at fault because it should check if it could handle what it received. Well, this time thats just how it is, IE7 does not check what it receive at all. In short, IE7 is unsafer in this case than IE6 was and the fault does according to previous statements from Microsoft no lie in the sending application (Firefox) but in the receiver (Internet Explorer 7).
HTTP/1.1 400
Oh please. You're wrong.
The Firefox bug was essentially that it was receiving URLs like "firefoxurl: -chrome javascript:alert('Oops.')" and then, instead of interpreting the URL as a URL it was interpreting it as a command line. This is clearly Firefox's fault - they configured IE to pass Firefox all URLs that start with "firefoxurl:", but neglected to tell IE that it should inform Firefox that it shouldn't emulate a UNIX shell when receiving the URL.
This is why almost all UNIX commands have that helpful "--" option, to suppress further option parsing. In fact, the Firefox fix was essentially to add that feature. They named it something braindead, but essentially they told IE that instead of executing "firefox.exe %s" it should execute "firefox.exe -- %s". Keep in mind that in Windows, the command line is not parsed, it's given directly to the command to parse as it wants.
Now contrast it with this case.
Firefox is giving URLs with INVALID CHARACTERS to Windows, and Windows is treating them as best it can, which can be exploited.
If Firefox were properly handling the URLs and not including invalid characters, this problem wouldn't be happening.
Looks like http://noscript.net/ will cover you if you're looking for a temporary fix.
Because technically it's not IE7 that's broken and allowing the exploit. It's Windows' routines that route and execute arbitrary protocol requests. It goes like this:
User clicks an email link, which starts with "mailto:" instead of "http:".
Firefox sees "mailto:" and realizes it's not a protocol it's designed to handle.
Firefox says, "Hey, Windows, I don't know what to do with a mailto: request. You handle it."
Windows compares the mailto: to its list of registered handlers, decides that Outlook Express is the application the user really wants, and launches it.
The bug, however, is that corrupting the part after mailto: with null characters causes that last step to malfunction and blithely pass the remainder of the request directly to the Windows shell, not Outlook Express, allowing it to do pretty much anything the user is allowed to. Two things should be clear here. First, that it's not really Firefox's fault. Invalidating or truncating the link if it contains null characters is certainly a good idea, but that doesn't mean that Windows' bug is justified. As has been pointed out, the bug would still be a problem for any other application that passes requests to the protocol handler.
The second thing is the answer to your question. Notice that Internet Explorer was not involved in this exchange at all. Even if it were registered as one of the protocol handlers it would be irrelevant, as the bug prevents the real handler from ever being launched. The reason IE7 is dragged into this is because something about the protocol handling routines changes when you install it, such that the exploit is not possible before and is possible after.
So it's a bug in the IE7 installation, not really IE7 itself.
Firefox users should not play the blame shifting game, but think that their loved product is responsible for the concept of "everything I click and do without authorising any additional actions on this browser should be secure". Yeah, IE7 received a command from a local app that alows bad stuff to be done? But a lot of local actions allows bad stuff to be done, it's the browser who should be controlling this kind of thing.
That's the same thing as Firefox exectuing a link with "C:\Windows\System32\whatever.exe". It's not "windows's fault for opening it", it's firefox's fault for sending the command.
A browser should NOT redirect commands to external apps unless the security boundaries of that operation are well defined and respected.
http://en.wikipedia.org/wiki/URI_scheme#Official_I ANA-registered_schemes
It gives you completely transparent secure shell access to remote machines from any KDE application. For example, typing fish://username@hostname/ in any file dialog will access the machine hostname using the ssh protocol, allowing you to savely load and save files from/to other machines without copying them by hand first.
To summarize: it is wonderful, and you won't know how you could live without it once you get used to it.
Allows remote access to files on machines running an SSH server, even if SFTP is disabled. If SFTP is enabled, you can also use sftp://. KDE also has protocol handlers for ftp, smb, webdav, and loads more. In all cases, you can just read files on the remote machine, even open them and edit them, as if they were local. So useful, and one of the (many) things I really miss when working on Windows or a Mac.