Browser Focus RIP

Mon, 12 Feb 2007 23:59:32 GMT
by pdp

There was a discussion on Full-disclosure and Bugtraq about a very peculiar vulnerability in Internet Explorer and Mozilla Firefox which can be used by attackers to trick victims into uploading local files.

It was Michal Zalewski who brought this subject back on the table. The vulnerability he described is not new. In fact, it is a variation of an issues discovered back in 2000. The peculiar thing about it is that it was reported to Mozilla's Bugzilla back then but never fixed.

If you read about what Michal's exploit does, you can easily get lost, so I will try to explain the issue as clearly as I can and provide you with some examples of how it can be used in real attacks.

The only component in the DOM (Document Object Model) that allows us to send locally selected files to a remote location is the file input box, usually declared as <input type="file"/>. This is not a standard input field because it has a browse button that is attached at the end and also because, once inside a multipart/form-data form, it can selected local files. Because of these characteristics, you cannot use JavaScript to set its value to a file path of your desire. If that was possible, everybody would be able to steal and list your file system remotely when you visit a malicious website.

However, by using a clever focus diversion tricks, attackers can make certain characters, that the victim typed, to leak inside the file input field. They can achieve that by using a filter that allows and disallows keyboard events based on the key code order in the file path string that needs to be retrieved.

In simple words, when the user types characters inside some text field, they are actually typing them inside a file input box, which filters out the unnecessary characters in order to compose the desired string. Everything else, is totally emulated, so the user thinks they are typing in the right place not knowing what is actually happening. The following text translates to /etc/shadow, which can be used to steal that particular file:

Bob! Check this out this is very cool: hei man, do you still need that wonderful CD I gave you long time ago?

You probably think that I am mad! Now, have a look at the following text, which shows all key characters that are required to build the file string.

Bob! Check this out http:[/]/www.[e] [t]his is very [c]ool: http:[/]/www.[s] [h]ei m[a]n, [do] you still need that [w]onderful CD I gave you long time ago?

Black magic! The filter removes the parts that are not required and only the characters that are needed are passed into the input field.

Although quite complicated, this attack is very real and probably should be taken seriously. If the attacker places the malicious JavaScript on a critical place where users are heavily using the keyboard, the chances of composing the desired string are quite high. Think about blogs, wiki entries, forums, etc. This issue can be shipped as part of an AJAX worm which propagates on the top of MySpace, for example.

In some situations the user doesn't need to type that much text at all. They can be tricked into typing the desired string in a much clever way. For example, the following sequence of characters composes the /etc/shadow string: b/etlc/shradow. It is not obvious that this 14 character long string corresponds to the 11 character long /etc/shadow path. Still, the question is how the attacker can force the victim to type these characters inside the page. Well, attackers need to be creative in this case. Check this two examples:

You visit a page requires a CAPTCHA. You type the letters b/etlc/ but you receive an error which tells you that your input was incorrect. Now you need to repeat the task and type the following sequence of characters: shradow.

Quite bad! My advice to you is to be careful. If you are using MySpace turn JavaScript off if possible. Don't use your keyboard on untrusted websites.

Archived Comments

Ben BuckschBen Bucksch
Mozilla’s Bugzilla back then and still, none has fixed it.
Not correct. As mentioned in and on FD, the big was fixed on Firefox trunk, before these reports. It's not yet on the Firefox 2 branch.
Paul RawdonPaul Rawdon
Re your vulnerabilities for Fire Fox and Internet Explorer 7. Have just tried the test with Internet Explorer 6 and Sea Monkey 1.0.7 (the replacement for Mozilla) and the same applies for these two as well. Fire-Fox's replacement Minefield appears to be immune to this problem.
The latest Firefox released to the public is and it's vulnerable. So the flaw is still unpatched!
I am experimenting with Opera. It seams to be vulnerable too, although I don't have a working exploit right now.
This is not good! This is the 2nd browser vulnerability in the last month that has allowed local file access. Well, actually the 3rd if you count the FireFox popup blocker issue as well.
Firefox has many more security vulnerabilities:
There are only very few websites that _require_ JavaScript, so I have disabled JavaScript by default. Most serious browser vulnerabilities were, are and will be based on active contents like JavaScript, JScript, Java, ActiveX, Flash etc.
OK folks, I cannot reproduce the bug in Opera, although sometimes I get the feeling that it is possible. It seams that Opera is in fact the most secure browser, or maybe I am wrong. Anyway, I will continue experimenting with my code and if I find anything interesting, I will post it here. Thanks.
Oh god Andrew, if you want to critisize software, at least use a source from a non-zealot then. This guy tries too hard to be one.
John DowdellJohn Dowdell
Thanks for the catch... "don't type lots on strange sites", I guess that's the takeaway.... :( I don't know about Apollo... it's still in development. It will use the WebKit rendering engine, as Apple's Safari does, but I don't know the local file permissions system myself yet. A public release is still a bit aways, but such focus transfers would be a good thing to doublecheck, thanks. jd/adobe
Thanks John. Is it possible to have a copy of the Apollo engine? I might be able to spot some problems that can be fixed before the actual release. I am a bit busy right now, but it will be interesting if we can do that.
John DowdellJohn Dowdell
There will be a public release soon, but it's not here yet... will redirect to the best page for latest info. tx, jd/adobe
: I would lower the opacity of the browser logos to make it more realistic :) cheers!
"kind of off-topic: " (was removed from the upper comment because I used "great than" and "lower than" ^^ ) - tighten the filters eh pdp ? :)
not really
a064c4b89718 a064c4b89718d00cfb93