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."

Awww, that's so cute

[varmint jerky (810306)]

Next thing you know they'll be coquettishly batting eyelashes at each other and accidently eating the same strand of spaghetti.

Re:

[mrbluze (1034940)]

It's certainly romantic, kind of - a bit like a fake pic of Bush and Osama in bed together that was floating around a few years ago.. ewwww!

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

Re:

[LordEd (840443)]

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.

Re:

[liquidpele (663430)]

"IE is *so* the bitch of that couple."

Yea, but Firefox has let itself go and has a lot of glut in it's mid section.

Nope

[The Bungi (221687)]

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

Neither on 2.0.2 xpsp1

[aepervius (535155)]

I could not make it work under such system either. Maybe it needs more ? Something which is not enabled on my firefox ?

Yep I have a boot.ini

[aepervius (535155)]

I am trying to get it work but it does not at all... Weird.

Re:Nope

[TheLink (130905)]

Well, in theory it's just for fishing a particular file with the filename that you type.

I'm not too worried about it, because in my office I use Linux and I run WinXP in a virtual machine, in that VM I use a nonadmin account for normal stuff - viewing and priting Word or Excel docs, instant messaging, AND I use the Run As feature to launch browser windows as yet another different nonadmin account. On the Linux host itself, I run firefox as a different user from my main user account.

So if I gather correctly, you can grab my bookmarks or downloaded files, IF I actually type all the letters to those specific paths? That's it?

I'd be more worried about Windows graphic driver exploits - graphics drivers seem a bit shoddy- plus they are all about performance, not security. And currently it's basically - Nvidia, ATI and Intel.

I've had weird things happen with Linux sound though so I wonder about the security of such stuff. I've pretty much given up on getting Linux sound to work properly for sustained periods of time (this on suse 10.0, perhaps I should try 10.2).

Re:

[Beryllium Sphere(tm) (193358)]

>So if I gather correctly, you can grab my bookmarks or downloaded files, IF I actually type all the letters to those specific paths? That's it?

If I'm reading this right, yes, with the added limitation that Firefox won't budge without a fully qualified path name, so you'd have to type a stream of characters that included a few backslashes.

If I'm reading this right, you could combine it with some exploit that breaks the same-origin policy and steal text typed in elsewhere, but then if you've broken the sa

Re:Nope

[TheLink (130905)]

Someone using the exploit can only grab any file on your filesystem that the user account your browser runs as has permissions to read, which may be significantly restricted (I found that hard to do on Linux in the old days, but I guess nowadays it should be easier with better filesystem ACLs).

If you use the same user account for work, ssh and browsing then you risk exposing stuff like:

~/.ssh/id_dsa
~/.ssh/id_rsa

Which in some cases might be more interesting than /etc/fstab ;).

Re:

[Phisbut (761268)]

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:

[ArwynH (883499)]

*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...

Re:

[ttldkns (737309)]

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.

How it works

[by Anonymous Coward]

Is the way this works by attaching keydown/keyup events to the document object, and then switching focus to the file upload field in order to let the user fill in the upload? Ingenious :)

So a browser would fix this by not allowing programmatic access to focus() for file uploads?

It doesn't sound like this would be particularly exploitable because you'd need them to type the letters in the right order (with other arbitrary letters as padding between this). Getting someone to type something might prove easier though now due to the prevalence of Capchas.

Re:How it works

[amrust (686727)]

Getting someone to type something might prove easier though now due to the prevalence of Capchas.

You took the words right out of my keyboard, no pun intended*.

It won't affect my commenting on blogs or sites that I normally frequent. But after that demo, I admit I probably won't look at captchas the same way again.

* OK maybe one quick pun.

Re:

[ShieldW0lf (601553)]

The reason focus() exists is to allow you to send the cursor to the field that needs correcting when you're doing form validation. It would suck if it wasn't available.

The real common vulnerability...

[NotQuiteReal (608241)]

Is 90% of those vulnerable are "regular users".

For good or ill, I don't know many regular users, of course it is lonely at times...

Re:

[jd (1658)]

I think I met a regular user once. I'm not entirely sure, though, as they seemed rather odd.

Doesn't work with Firefox 2.0.0.1 on Windows XP

[by 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:

[Ctrl-Z (28806)]

Do you have a C:\boot.ini file?

It worked for me (yikes!) with 2.0.0.2 on Windows 2003; I presume XP would be similar.

Re:

[SashaMan (263632)]

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:

[nmb3000 (741169)]

I tried with a limited user account, but of course boot.ini can only be read by administrators.

False. These are the defaults on XPSP2 and Win2003:

C:\>cacls c:\boot.ini
c:\boot.ini BUILTIN\Power Users:R
BUILTIN\Administrators:F
NT AUTHORITY\SYSTEM:F

It works for anybody >= Power Users.

Then I tried with an administrator user, and still boot.ini wasn't shown.

It works for Administrators too.

Fud?

No

Re:

[Tim C (15259)]

Works fine with an admin account on XP Pro SP2 and Firefox 2.0.0.2 and IE 7.

Also, there is no need to type all that jibberish about cheese

The gibberish is there to demonstrate pulling selected key presses out of the string that you type in. Getting someone to type a path to a file would be tricky; pulling a path out of a reasonably long message would be much, much easier (although getting enough slashes would seem to be unlikely...)

Vulnerability doesn't work on Vista (Sort of)

[by Anonymous Coward]

Vulnerability kinda doesn't work using Firefox 2.0.0.2 and Internet Explorer 7 (Both 32 bit and 64 bit version) on Vista Business Retail.

I had to create a Boot.ini file in my C: drive since Vista doesn't have it there anymore. IE7 and Firefox will be able to pull information out of the file if you have permissions to read the file but if you don't it won't work. This is probably why some people are reporting it doesn't work in Win XP with a user account. Only admin accounts are affected because the user

Re:

[MichaelSmith (789609)]

It seems that the person using this exploit would have to know the exact filename and path of the file he wants so this seems like a minor issue.

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.

OT: CS:101 - Lost updates.

[TapeCutter (624760)]

"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 "offici

Re:

[MichaelSmith (789609)]

If the document is already distributed, what is the point of an exploit to download it?

Maybe you want the meta information, or the letterhead, embedded macros or a later version.

Try as I might...

[oceanstream (1004835)]

I cannot get this flaw to work in Firefox on Linux. I've gawked and re-written the code several times, created dummy text files that are mode 0666, to no avail. I think it could be exploitable only under the loosest of security profiles. Did I miss something from TFA that makes this windows-specific?

Re:

[gordgekko (574109)]

Who modded this guy insightful? The summary says it's common to IE and Firefox running on Windows.

Re:

[nmb3000 (741169)]

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

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

Works on FireFox under Linux

[smiggly (235904)]

It just takes a few changes. Try this:

http://www.thanhngan.org/fflinuxversion.html [thanhngan.org]

Sad realization

[by Anonymous Coward]

So...Safari on the Mac is A-OK?

Anyone else try Opera ?

[Joebert (946227)]

I tried this on
Windows XP
As Administrator
With No 3rd party anti-virus or anti-spyware protection whatsoever (total of 20 processes running including Opera)
Opera 9.10
All scripting enabled
Checked the presense of boot.ini

And while it did continue to a new page when I typed the phrase, that new page didn't have the contents of my boot.ini file.
Just a message telling me what that page was about.

Re:

[KDR_11k (778916)]

When I try that the input field that's supposed to contain the filename just collapses to a 2 pixel wide line and nothing else happens.

They already share a vulnarability...

[TEMMiNK (699173)]

the user.

Requires javascript

[pedrop357 (681672)]

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.

Variation on an old bug

[jesser (77961)]

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:

[Kopretinka (97408)]

I'm not sure why this is getting press now, given that a very similar exploit has been known and public since October 2000...

If it gets press, the fix might finally be released, perhaps?

What about Konqueror? Or Safari? Or Opera?

[Phil Urich (841393)]

Is this a case where using a really non-standard browser (well, I mean, Konqueror is standard for KDE but it's not like KDE is a common household word in middle America, heh) leaves one untouched? Or is this potentially a wider implementation problem? I did RTFA, and it is speculated upon. In Michal Zalewski's bug submission:

Opera is unlikely to be vulnerable to that exact attack, because it is impossible to focus on the file input text field, only on the 'browse' button; other browsers were not tested, but I would expect at least some to be susceptible (naturally, on MacOS X or Linux, test cases have to be modified to access an existing file).

However this leaves the question mostly still open (even Opera perhaps, if something related that took into account Opera's different handling of these cases, right? Or am I reading wrong?).

The vulnerability is called 'users'

[mrkitty (584915)]

No matter how much you secure something, you're always going to have to deal with users. They will always do stupid things regardless of what safeguards you have in place.

And the workaround is...

[camcorder (759720)]

You should disable javascript, yet again.

Re:

[holloway (46404)]

Is it invulnerable because the file they happened to choose is restricted (c:\boot.ini) or because the browser is now smart enough not to give javascript focus to file upload fields?

If so then it's still vulnerable because they'll release a patch to stop hackers from uploading user files, like those with predictable filenames. It seems wrong to say that IE+Vista aren't vulnerable when the IE bug still exists.

(of course if IE7 prevents giving focus to the upload field then I'm wrong -- but I don't think that

Re:

[jasonwea (598696)]

The test as it stands now is not valid for Vista as (afaik) it doesn't have boot.ini.

From what TFA says though, protected mode protects IE on Vista.

Re:IE7 Vista

[evilgrug (915703)]

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

Re:IE7 Vista

[brainhum (869270)]

The latest Web 2.0 Captcha:

C:\ W IN D O W S\ sys tem 32\config\S AM

You heard it here first! /.

Re:

[RuBLed (995686)]

Easy, reply to this and type the words "I want a cute bug picture. Now. \."

Re:

[Joebert (946227)]

Don't complain, we might end up with a picture of a bleeding asshole, while cute to some of us, I don't think the rest of us would appreciate it.

It could be worse.

[jd (1658)]

If they rewrote XRoach as a secure Java applet, then the cockroach would climb around the screen and hide behind windows until you squash it by clicking on it. Hmmm. Actually, that's not a bad idea - can someone on the Slash code development team add this?

Re:

[SanityInAnarchy (655584)]

Well, seeing as file upload fields probably cannot have a default value, I'd assume this would be validated the same way. I'll leave it to someone else to test that theory, though.

Re:Offtopic rant

[julesh (229690)]

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.