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.
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.
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)
-Docvert converts MSWord to OpenDocument, clean HTML
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?
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.
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..."
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.
It didn't protect IE on Vista for me. I created a dummy boot.ini and IE7 Vista happily spat it out.
The latest Web 2.0 Captcha:
C:\ W IN D O W S\ sys tem 32\config\S AMYou heard it here first!
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!
"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.
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!
You'll have to go a long way back to claim this one.
It just takes a few changes. Try this:
http://www.thanhngan.org/fflinuxversion.html
Firefox obviously violates M$ IP if there is a shared venerability.
Power to the Penguin!
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.
Comment removed based on user account deletion
I could be wrong, but I don't think you can really predict the character output of a keydown event, as it happens on a keystroke-level, before important factors (dead keys, shift and caps state, keyboard layout) are analyzed to determine the final character. The appropriate event for that would be keypress, but on my tests it can't be hijacked (maybe there could be some trick). So, you'd need a few initial keystrokes to test which characters they produce, and then attempt to guess the layout being used.