IE and Firefox Share a Vulnerability

hcmtnbiker writes with news of a logic flaw shared by IE 7 and Firefox 2.0. IE 5.01, IE 6, and Firefox 1.5.0.9 are also affected. The flaw was discovered by Michal Zalewski, and is easily demonstrated on IE7 and Firefox. The vulnerability is not platform-specific, but these demonstrations are — they work only on Windows systems. (Microsoft says that IE7 on Vista is not vulnerable.) From the vulnerability description: "In all modern browsers, form fields (used to upload user-specified files to a remote server) enjoy some added protection meant to prevent scripts from arbitrarily choosing local files to be sent, and automatically submitting the form without user knowledge. For example, '.value' parameter cannot be set or changed, and any changes to .type reset the contents of the field... [in this attack] the keyboard input in unrelated locations can be selectively geared toward input fields by the attacker."

Nope

[The Bungi]

Not Firefox 1.5x under a non-admin account on XPSP2, though I admit that setup, while sane, is unfortunately not really common...

Doesn't work with Firefox 2.0.0.1 on Windows XP

[Anonymous Coward]

I tried with a limited user account, but of course boot.ini can only be read by administrators. Then I tried with an administrator user, and still boot.ini wasn't shown. Fud?

Also, there is no need to type all that jibberish about cheese. Just slowly type in:

C:\boot.ini

Type it too quick, and the javascript in the background won't be able to keep up with the rate of keystrokes you enter.

Re:Doesn't work with Firefox 2.0.0.1 on Windows XP

[Anonymous Coward]

The gibberish about cheese is used to show that a file name is being extracted from a string that would otherwise be considered benign. FWIW: This does affect FF 2.0.0.2 on XP under my admin account.

Requires javascript

[pedrop357]

I use Noscript to block javascript. The exploit didn't work until I allowed javascript for that site.

New/unknown sites won't be able to do this, but my previously "trusted" ones will.

Re:IE7 Vista

[evilgrug]

It didn't protect IE on Vista for me. I created a dummy boot.ini and IE7 Vista happily spat it out.

Variation on an old bug

[jesser]

I'm not sure why this is getting press now, given that a very similar exploit has been known and public since October 2000 (bug 56236). It was even fixed on trunk in September 2005, but left unfixed on branch intentionally because we weren't confident we had the UI right.

Zalewski's version is bug 370092, and he was unhappy when I marked it as a duplicate of bug 56236.

Re:Doesn't work with Firefox 2.0.0.1 on Windows XP

[SashaMan]

You are missing the point. The demo program just uses boot.ini as an example, but the core problem of redirecting keystrokes to a file upload is the issue, because any file with a well-known location could be uploaded. You could write a simpler program yourself by just using two fields, a text box and a file input, and show how typing in the text box immediately appears in the file input.

Re:Try as I might...

[nmb3000]

Did I miss something from TFA that makes this windows-specific?

I think the presence of a C:\ might help.

Re:Nope

[ArwynH]

*Doh*

I wonder how many other /.ers tried it, like I did and couldn't get it to work because they forgot to turn off NoScript...

OT: CS:101 - Lost updates.

[TapeCutter]

"Often when somebody prints out a document to distribute at a meeting they print the full path to the document in the footer of every page. This has always seemed like a bad idea to me."

Managing documents is not a task to be taken lightly, especially when the document is the product of more than one person, document management systems work in essentially the same way as source control systems. The reason the file is on the footer is to deliberately identify where the document came from (ie: is it "official" or just someones private backup copy). It is also (ironically) a simplistic security measure that makes hard copies somewhat trackable.

Removing the path is a "security through obscurity" solution that would impose an inconvienince on the people who create/edit/review documentation and would increase the risk of corrupt documentation (ie: lost update syndrome).

OTOH: I'm sure there are cases where "burning" is demanded because "shreading" is considered too risky, but I rather think they would be the exception rather than the rule.

Re:Offtopic rant

[julesh]

I abhor the use of the word "enjoy" in the media and by marketing people in particular. Form fields may *have* protection; they do not *enjoy* protection because they aren't fucking conscious. And nobody enjoys, say, the protection of car insurance. I don't sit at home feeling all warm and fuzzy because I've just taken out some policy.

Seeing this in tech news just shows how much this has spread. I no longer want to use the word enjoy at all because every time I hear it, I am reminded of this usage and feel a twinge of annoyance.

I want my English language back from these idiots!

Online Etymology Dictionary
enjoy
c.1380, [...] Sense of "have the use or benefit of" first recorded c.1430. [...]

Online Etymology Dictionary, © 2001 Douglas Harper (Link) [reference.com]

You'll have to go a long way back to claim this one.

Re:Nope

[ttldkns]

Ahhh, but then they know valid account names on your box to start blasting with a dictionary. Imagine if you ran an SSH server where only users in a certian group could ssh in. Then grabbing /etc/group can tell you which usernames to focus on.

Re:Nope

[Phisbut]

Interesting targets would be e.g. /etc/passwd

Other than getting a full list of user names on my system, what does the /etc/passwd file contain that I don't want others to know? It's not like passwords are stored in there or anything...

Re:Awww, that's so cute

[LordEd]

Maybe the vulnerability they share is "that they both run in Windows".

That's a bit unnecessary. TFS(summary) even says "The vulnerability is not platform-specific, but these demonstrations are -- they work only on Windows systems."

Save the windows bashing for actual causes.

That's mostly right, actually

[Anonymous Coward]

To do something useful with the exploit, the attacker needs to know the name and location of a desired file, and the browser has to be permitted to upload (read) the file. Obviously one dramatic way to use the information gained is to hack the victim's system. Most OSes, properly configured, don't let ordinary users (or their browsers) read critical system files, but Windows does.

Even on better-designed OSs, though, the exploit has uses for espionage and spam. People tend to put data files in predictable places, using predictable names. With a little luck or a large pool of visitors you can get financial information from QuickBooks, personal info (and valid email adresses) from Outlook contact books, business information from powerpoint documents stored in My Documents, or the complete set of somebody's recent email correspondence.

The focus-diversion technique sounds awkward at first, but I've been thinking of ways to make it more reliable without the user getting suspicious (eg, trick them into typing several backslashes in between other text) - and if I can think of them, others can too.