A serious browser vulnerability, but whose? A serious vulnerability that causes Internet Explorer to launch Firefox and execute a malicious payload is sparking debate about exactly who is responsible for the flaw. The vulnerability, which was widely reported on security blogs, allows an attacker to remotely execute malicious code on a machine that is running IE but also …
In this case, if IE decided to do any parsing, MS would be blamed for somehow controlling the user.
IE can handle that data, therefor passes it along. Firefox should KNOW better than to accept data from ANYWHERE (be it IE, a browser, a link, etc) without validating it.
You can't say, well, I trust IE so its IE's fault. It's like me saying, he told me his name was Shirley, so I believed him. It's HIS fault.
I'm no IE fanboy, but any first-grade programmer knows that if you're accepting input from other programs, the onus is on you to validate it. Trusting data fed to you by external sources is idiocy. Firefox should own up to this one and keep its longstanding tradition of putting user security ahead of its own interests.
A downcheck to Microsoft for allowing the internals of IE to be corrupted to pass a bad command...
A downcheck to Firefox for allowing a piece of external data into its internals without first checking it.
While I have not written anything for a Browser, I write for quite a few database systems that have to interface with various other systems; and the first rule is - external data is *always* suspect (internal data is potentially suspect).
Tough to say where the flaw really is. The security risk comes using IE, but FF executes the bad code. The attitude is the thing to note here. MS will not dare admit that any of it's programs ever have any kind of flaws of any kind. FF came out and said we'll patch it to not accept anything from IE. IE SHOULD be coming out saying we'll patch it not to pass anything to FF. Mozilla is getting things taken care of, MS is trying to assign blame to someone else and not doing anything about it. Whether the flaw is in FF or IE doesn't matter, the path is closed off so the exploit will not work anymore, but the fact that only one gate is closed because of attitude (read God-complex) is a problem.
The real question is, why is there a custom FF handler in the first place? There should be no need for such an additional, non-standard construct and putting one in is just asking for trouble.
I'm a FF fan, but in this case IE appears to be doing what it's meant to do - passing data onto a third party handler application. It's not it's fault that the data is incorrect or invalid, it's for the third party handler application to do that checking, besides, there's no way that IE can know the exact validity of a URI for a third party handler.
I agree with Nick, how is this supposed to be an MS problem? IE receives a request which needs to be handled by a 3rd party app, it doesn't understand it, can't do anything with it (and obviously isn't vulnerable from it), so passes it on to the app which can process it.
It's all very well saying that IE should block it, but imagine the outcry there would be if IE started blocking all requests to 3rd party apps which it didn't know how to handle! People would then complain that MS was stopping 3rd parties from developing new things since they'd be beholden on MS to update IE to understand their new tech. It's a no win situation for them.
Looking at it slightly differently, what would happen if there was a bug in a 3rd party app which wasn't a browser? Say Adobe Acrobat had a vulnerability relating to opening online PDF's? IE doesn't know about the internals of a pdf, it just knows that they should be passed to Acrobat. Should it block the request because it doesn't understand it, or should the onus be on Acrobat to make any required checks when it is passed the file to open?
"Attacks using the firefoxurl URI will probably be initiated through the use of XSS or CSRF
Although these examples are very simple, other, more malicious attacks can probably be initiated."
The FF addon NoScript handles this very nicely by blocking XSS, if I'm not mistaken.
So, I guess I'm safe...
Besides, the exploit needs that the user have FF2 installed *and* use IE.
Surely someone who has FF only uses IE to go on *trusted* and *poorly made* websites that only work with IE, like train or hotel reservations, company intranet...
It's unlikely that a FF user will go browser *doubtful* (*cough* porn *cough*) sites with IE.
I have found that without NoScript, Firefox lets in more bugs than a entomologist looking to restock his lab. Plus having to allow things when I want to use a website properly is annoying. IE7 blocks things automatically and I lose no functionality.
In fact for quite some time now I have had no problem when using IE7.
The reason why I might think of IE7 is because all Microsoft products are flawed and always critically, and they always need updates. They never get things right.
I haven't read enough into this to learn exactly how the exploit works. It would appear that as a user I can run a command like:
firefox http://www.test.com
and get FF to load http://www.test.com similarly I can run
firefox "firefoxurl://foo" –argument "my value/"
which also seems reasonable.
Programs should be written in such a way that they can prevent the user causing damage, therefore this is a problem with FF not IE.
(The fact that IE can call firefoxurl is irrelevant, the bug, imho is with FF willing to take arbitrary, unchecked, user input)
I'd be interested to learn if others agree with this viewpoint.
Charlie
It's all kinda childish, like 99% of forum discussions on the Net. Why ? Because it's mostly children (meaning fanboys) that participate.
I'm surprised that the rhetoric here has remained quite calm and rather level-headed. Must be the moderators putting down 90% of the comments.
Much as I'd like to join in an IE-bashing spree, this one is definitely Firefox at fault. An application should be able to take anything thrown at it from any input source and deal with it. If there's a way of injecting something from an uncontrolled source that bypasses some of the validation checks then that's definitely a bug.
"Jesper Johansson, a former senior security strategist for Microsoft, similarly argues that "most definitely" the problem isn't caused by IE."
Poor old Jesper - not only did he have one of the "top 10 worst jobs on Earth", but of course he lost his job some while ago when Microsoft realised that they didn't *need* any security in their products, so why bother having a strategy...?
Oh, and Jesper adds that the world "most definitely" isn't round, and that he "most definitely" isn't writing with a big green wax crayon because, where he now is, they don't let him hold anything sharp.
Notice that Firefox users with the NoScript add-on installed have been already protected both from MacManus/Larholm remote code execution and from Rios "Universal XSS" since June, the 22th, see http://noscript.net/changelog#1.1.4.9.070622
More in general, they're protected from chrome privilege escalation gained by opening non-chrome URLs in top-level chrome windows (Larholm's PoC) and from javascript: URLs being loaded in externally opened browser shells (Rios' "Universal XSS" PoC), no matter if attempted through the "firefoxurl:" handler (like in this specific case) or by other yet unknown means.
Hence, these protective features are here to stay, since the upcoming Firefox 2.0.0.5 just fixes the "firefoxurl:"/command line case.
Once again... the almighty Microshaft brings about more trash to the world..
Not so good that firefox did that either.... but thats secondary.
IE is to blame first and foremost because it's the "weakest link".
Honestly... to blame firefox means you need to blame the entire operating system for letting it happen.. not to mention the winblows firewall...err... wait a second.. i already do... never mind.
1. What are the standards for passing requests on?
If the request should just be passed with no regard to content then IE is not contributing to the problem, if however there is a standard for passing on this request and IE is not adhering to it then is is adding to the issue.
2. Should FF assume it only gets 'clean' data?
This is the same question from the other side, however if there is no agreed standard then FF should validate this data (some have argued that this should be validated even without a standard, which has some mileage, take ever expanding jpg's as a similar issue)
In summary, FF will be fixed to stop this issue because IE can send bad data, if it's not IEs job to validate the data then it's not it's fault.
Does the browser security depend on where the data comes from - if it is the wild internet, be cautious - if it is from the local hard-disk then less cautious. Like the SQL example posted above - external data watch out - internal data be cautious.
I imagine this crack works by Firefox assuming data from IE is good or IE saying the data is good (i.e. local) and Firefox believing IE or both.
IE should not say passed through data is safe, if it does.
Firefox should not assume data is safe, if it comes from a source with lax credentials.
The only references I can find are to this vulnerability. A cursory test returns a warning that sources should be validated and there is a delay before a 'launch application' button in the dialogue ungreys itself. Running firefoxurl://notepad.exe and pressing 'Launch Application' generates a new tab with the warning dialogue. Not a good testing environment but it must take a bit of work to find these things out.
SAM:
You got the wrong URL.
JACK
I did not get the wrong URL. I got the right URL. The wrong URL was delivered to me as the right URL! I accepted it, on trust, as the right URL. Was I wrong? Anyway, to add to the confusion, it crashed on us. Which, had it been the right URL, it wouldn't have done.
I don't really care whether or not it's IE or Firefox. Actually, I'll fall into the 'It's both' camp. But the important thing is the response. To work to make sure it won't happen again, regardless of whose fault it was, is the correct response. To do nothing beyond finger pointing is not the correct response.
... I can't find a Linux distro that ships with IE and Microsoft doesn't seem to offer their browser ported to 'nix. I feel deprived.
On a less facetious note, I'm not entirely sure why real-world users would fall foul of this cross-browser handler exploit. If they have FF installed, one assumes they'd use it in preference to IE except for sites which rely on M$ tech (Active X and so on) or IE ident in the browser header. In the latter case, there's an FF add-on to spoof the useragent header string. Or am I missing summat?
BTW, is 'facetious' the only word that contains all five vowels in alphabetic order?
I've just attempted a number of different ways of launching this exploit, but can't seem to get it to execute except from IE.
* Attempting to launch it by pasting the URL into FF shows a warning with the full URL. Accepting this warning just brings up another warning about "firefoxurl:test". Accepting this one just brings up another, etc, creating a new tab each time.
* Attempting to launch it via the ShellExecute API doesn't work. FF warns about "firefoxurl:test", not the entire URL.
* Launching the URL from IE (either via the link or pasting the URL into the address bar) causes the exploit to run.
It certainly seems that IE is partly to blame, because it does something different in how it executes these links. Perhaps MS should patch IE so that it uses standard mechanisms to launch these links, rather than whatever method it currently uses.
Windows - ROFL
Re-affirms my disbelief of people porting IE to Linux via WINE. How many slaps in the face like this do you need before you realise that no-means-no? I'm with Max - wait until this results in shots at winword.exe, cmd.exe, rundll32.exe, explorer.exe .. etc ad nausea .. you can almost sense the silent update coming ..
> BTW, is 'facetious' the only word that contains all five vowels in alphabetic order?
No, search via;
[b-d,f-h,,j-n,p-t,v-z]*a[b-d,f-h,,j-n,p-t,v-z]*e[b-d,f-h,,j-n,p-t,v-z]*i[b-d,f-h,,j-n,p-t,v-z]*o[b-d,f-h,,j-n,p-t,v-z]*u[b-d,f-h,,j-n,p-t,v-z]*
Abstemious
Abstentious
Annelidous
Arsenious
Avenious
Caesious
[Facetious]
Materious
Placentious
Tragedious
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
