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

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

Nope

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

Re:Nope

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:Nope

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 ;).

How it works

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

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.

Offtopic

Am I the only one who kinda freaks out every time he sees this 'bug' picture? Can't slashdot have a cuter bug image?

The real common vulnerability...

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

Doesn't work with Firefox 2.0.0.1 on Windows XP

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.

Vulnerability doesn't work on Vista (Sort of)

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 accounts probably don't have read access for boot.ini.

This means that the vulnerability won't be able to access any system files but it could potentially access sensitive data you have because you'd obviously have permissions to read those files (i.e. Word documents on your desktop).

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. The real risk is with system files because the directory and filenames for those will most likely be the same on most systems but those can't be read and I'm not sure what you'd do with the info anyway...

Try as I might...

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?

Works on FireFox under Linux

It just takes a few changes. Try this:

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

Sad realization

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

How does that even count?

Yes, because we all start typing "C:\repair\sam" the moment a website finishes loading...

C:\ is my boot drive.

Incidentally I'm lactose intolerant.

I wonder how quickly this may become a real threat in the wild and how quickly the manufacturers can patch it...

Perhaps...

they both run on windows?

Anyone else try Opera ?

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.

They already share a vulnarability...

the user.

Firefox 2.0.0.2 + IE6

The POC worked in both Firefox 2.0.0.2 and IE6 on Windows XP SP2. It worked as well typing various phrases besides what it told me to type.

Below should be a copy of your C:\BOOT.INI file. If nothing is
shown, chances are you don't have this file in the first place,
your account has no permission to read that file, you didn't use
a vulnerable browser, or I screwed something up.

=== RECEIVED DATA ===


[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Micro soft Windows XP Professional" /noexecute=optin /fastdetect

Requires javascript

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.

Possible workaround

If you copy/paste the text, the Firefox demo doesn't work.... a possible workaround?

The Firefox demo also is sensitive to the typing speed, for example, if you type "bnoot" instead of "boot" and you type the "n" very quickly after the "b" the demo tries to open the C:\bnoot.ini file instead.

Variation on an old bug

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.

What about Konqueror? Or Safari? Or Opera?

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'

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

You should disable javascript, yet again.

I thought this was fixed ?

This was news a while ago, but there have been more [secunia.com] since then, all of which are fixed in the latest update of Firefox (AFAIK).
The Reg [theregister.co.uk] carried this story yesterday. I don't know if IE7 is fixed yet, but I had an auto update to Firefox (2.0.0.2), 3 days ago.

Doesn't work here

Windows XP Pro, SP2. Running Firefox 2.0.0.2.

It does catch the first "c" I type, but it stops after that - colons aren't caught.

Two theories:

  1 - One of my numerous Firefox extensions is interfering with the Javascript
  2 - I'm using a German "kezboard". Colons are in a different place. Now off to check if my uppercase "Ö" gets captured...

it's a POC

for everyone out there who has commented that ooooo it doesn't work on my non-admin account, ooo I lock down access to my boot.ini (listen if you really want my boot.ini, email me, I'll send it to you), oooo I run linux.

It's a proof of concept about a focus redirect exploit (bug? that's a misnomar). The example itself (displaying boot.ini) is not the exploit, the exploit is the hijacking of selective typed text in one textbox and applying it to another. The application of this exploit could be much different than displayed in this example.

NoScript stops it

First time I tried, it did not work. Then I disabled NoScript to give permission to that site, then it workd, it showed me my c:\boot.ini. Since I permit only very few trusted sites to execute scripts in my work machine I am safe here. But the common use laptop in my home would be vulnerable. Stil it is only unauthorized snooping of my files. Not as bad as drive by downloads or system modifications.

Wrap it up!

And that kids, is what happens when you don't use condoms. Firefox should have known better.

The race is on!

It will not only be very interesting to see who releases a patch first, but also by what margin.

IE7, Firefox2, Opera9, Konqueror and Safari

IE7, Firefox2, Opera9, Konqueror and Safari share a vulnerability: Javascript.

Of Course They Do!

It's called Windows!

IP violation

Firefox obviously violates M$ IP if there is a shared venerability.

With all these FireFox vulnerabilities...

... I can not but wonder why FireFox is considered to be a secure browser. It seems to have more security issues than IE lately. Is the underlying code quality of FireFox that bad?

Minefield

It didn't work for me on Firefox 3.0a3, so I guess there's a good reason to be on the bleeding edge. :D

Detection seems a bit random

It worked for me (Firefox 1.5.0.9, XP), but I had to retype it a few times as it didn't always detect the keystrokes. Though, I'm sure there are many ways to implement this type of attack. Hopefully the devs won't just patch this particular vector.

wtf?

So the user takes the form and positions it off screen where the input type="file" tag is.

The real problem lies in that it is there, just not visible in the browser.

I can accept that. The key is style="position: absolute; left: -500px;...

And then the div tag's style: style="position: absolute; left: 510px;... that takes the form and puts it back to pop

Then the dev closes the div tag and places the file field to the left.

Clever. But there is some security in obscurity. Knowing which files to grab that are of real use... I suppose grabbing someone's registry could yield something interesting about the user, and then parsing through it to find relevant keys and then using another form to get something of real value would be about the most useful thing you can do...

I think it's really sweet

That both browsers are mature enough to share.

Hack of a Work-Around

This vulnerability isn't present when viewing the infected page from IETab/IEView in Firefox 2.0.0.9. Can anyone explain why that is?

I've used it for years!

I don't really see how this is an "exploit," since it seems to require user intervention. But in any case, I've been doing this using VBA with IE to automatically fill out file upload fields - for years.

I know, I should have used Curl or something back then, but it was Access VBA. Don't blame me!

The real "fix," though, would be to remove the text box entirely and just have a browse button.

Really Needs a Proper Fix

That exploit really is instructive. There is simply no end to the creativity of the hacker.

Maybe we can finally dispense with the whole clunky two-step file upload. I mean who ever actually types a file name into the file upload field. You press the browse button to populate the field and then hit submit. Smart sites actually script it to one step by doing a submit off an onchange event in the file field. There really is no need to ever present a field to start with and it is just an accident waiting to happen. The upload should be one step that cannot be "messed" with.

Re:IE7 Vista

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's the case. The same bug exists in IE7 on Vista)

Re:IE7 Vista

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

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

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:innerHTML

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

Furthermore, words change in meaning over time

This is patently false. This conversation is very nice, so I'm going to go and play a gay game, get a cool drink, watch a counterfeit video and get some truly bad snack food.

Re:Offtopic rant

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:Offtopic rant

the media and by marketing people in particular [...]
I want my English language back from these idiots

You have to realize how ridiculous these people are. They babble for a living.

I must warn you that I have heard marketing people talking about their "Spider Sense tingling" and needing to "ping" colleagues for information.

"Your language" has been and always will be hostage to idiots. If you want to feel more secure, I suggest that you change your language from English to C. The C compiler is much stricter.