×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

IE and Firefox Share a Vulnerability

kdawson posted more than 7 years ago | from the upload-with-daring-and-whimsy dept.

Bug 207

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

207 comments

frosty piss (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18163564)

big floppy donkey dick

Re:frosty piss (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18163752)

I know you are, but what am I?

Re:frosty piss (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18163874)

Do you feel like more of a man for modding me down? I bet you told all your friends about it. LOOOOOSER!!

Awww, that's so cute (5, Funny)

varmint jerky (810306) | more than 7 years ago | (#18163574)

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

Re:Awww, that's so cute (1, Funny)

Anonymous Coward | more than 7 years ago | (#18164020)

IE is *so* the bitch of that couple.

Re:Awww, that's so cute (3, Insightful)

mrbluze (1034940) | more than 7 years ago | (#18164090)

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:Awww, that's so cute (0)

Anonymous Coward | more than 7 years ago | (#18164174)

Not even close to being funny. The crap that gets promoted on /. ...

IE7 Vista (0)

Anonymous Coward | more than 7 years ago | (#18163582)

I can confirm that IE7 on Vista is not vulnerable. Probably has to do with that whole Protected Mode thing.

Re:IE7 Vista (2, Interesting)

holloway (46404) | more than 7 years ago | (#18163684)

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 (2)

jasonwea (598696) | more than 7 years ago | (#18163820)

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 (5, Informative)

evilgrug (915703) | more than 7 years ago | (#18163984)

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 (5, Insightful)

brainhum (869270) | more than 7 years ago | (#18164024)

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:IE7 Vista (0)

Anonymous Coward | more than 7 years ago | (#18164582)

Not quite, the live in-use SAM isn't readable even to Administrator accounts. Try %SYSTEMROOT%\repair\sam.

Also, 99% of windows boxes hitting the average malware site are going to already be logged in as Administrator and have no password anyway, so cracking their hashes would be fairly pointless. This could theoretically be used in a targeted corporate phish/hack though.

Nope (3, Informative)

The Bungi (221687) | more than 7 years ago | (#18163606)

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 (1)

aepervius (535155) | more than 7 years ago | (#18163668)

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

Re:Neither on 2.0.2 xpsp1 (0)

Anonymous Coward | more than 7 years ago | (#18163724)

Huh, that's weird. It works for me on 2.0.0.2 XPSP2 . Do you have a c:\boot.ini ?

Re:Neither on 2.0.2 xpsp1 (1)

nmb3000 (741169) | more than 7 years ago | (#18164054)

Neither on 2.0.2 xpsp1

It does work in Firefox 2.0.2 on XP SP2 with standard options set.

I think the problem some people are having may be that when you type too fast or hit extra keys like backspace or enter, the event misfires and doesn't catch the character. If you type exactly what it says without making any mistakes, it will work. You can tell if it's taking the keystrokes right by checking the box down below. It should start spelling out "C:\boot.ini" as you come across the first occurrence of each character. The IE implementation seems better at catching characters as they come in.

You can test it easily by just slowly typing "C:\boot.ini" in the box.

That said, this is one of the more interesting exploits I've seen. There are no "holes" per se, just an interesting use of forms and javascript, but not too much to worry about for most people I'd imagine. At least on Windows it's a little harder to fish for filenames because there isn't a shortcut for the user's home directory. On XP you'd need to type "C:\Documents and settings\%username%\My Documents\foo.txt" while I assume on Linux you can enter "~/foo.txt" in a form field it will work (?).

Just one more reason not to keep your hidden stuff in ~/secrets.txt I guess.

Re:Nope (4, Interesting)

TheLink (130905) | more than 7 years ago | (#18163690)

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 (1)

Beryllium Sphere(tm) (193358) | more than 7 years ago | (#18164142)

>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 same-origin policy you could do that anyway.

Re:Nope (2, Interesting)

Anonymous Coward | more than 7 years ago | (#18164280)

Isn't anyone using Google Mail? Just compose a new mail, and attach a file. Type in the file name, and Gmail will automatically upload it without you submitting anything. The "feature" has been there for ages, so frankly I'm puzzled why all the fuss now and not months ago?

So now that this is a bug, it makes Gmail an exploit, which makes Google do evil.

Boycott Google, Hail Microsoft! ..right?

Re:Nope (1)

acidrain (35064) | more than 7 years ago | (#18164288)

Ok then, can anyone name a file on my XP box that has a standard name that they could use a copy to do some damage with?

Then I'll make an evil JavaScript version of typing tutor...

Oh, and if were comparing notes I'm surfing as an administrator in XP using firefox, and my sound does work. And I disabled the ability to transfer money out of my account using my online banking.

Re:Nope (1)

YeeHaW_Jelte (451855) | more than 7 years ago | (#18164380)

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

No, someone using this exploit could grab any file on your filesystem that you have permissions to read. Interesting targets would be e.g. /etc/passwd, /etc/fstab, you name it.

Common mistake made here: most of these exploits are pretty harmless by themselves ... it's the combination that hurts.

Re:Nope (1)

holdenholden (961300) | more than 7 years ago | (#18163860)

Didn't work for me. Maybe I should have set NoScript to "Allow Scripts (Globally)". Stupid me. As soon as I finish typing this, I will.

Re:Nope (2, Informative)

ArwynH (883499) | more than 7 years ago | (#18164100)

*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:Nope (0)

Anonymous Coward | more than 7 years ago | (#18163902)

Not Firefox 1.5x under a non-admin account on XPSP2

The bug works, the specific demonstration does not. As the page says, you need read access to c:\boot.ini. Non-admin accounts do not have this read access, but I'm sure you can think of some other sensitive files that you can read.

Re:Nope (1)

donaldm (919619) | more than 7 years ago | (#18164306)

Does not appear to work with Firefox 2.0.0.1 on Fedora Core 6. Still unless someone can prove that this affects me and I need to upgrade immediately I will upgrade this coming Friday as part of my normal update procedures.

Re:Nope (1)

hahiss (696716) | more than 7 years ago | (#18164544)

The test page only works with Windows because it is looking for a specific file, but the exploit is general:

"Both examples [IE & Firefox] are Windows-specific, and require C:\BOOT.INI to exist and
be readable by users. The attack itself is not limited to a particular
operating system, but I decided to provide a demonstration for the most
popular desktop OS - *nix versions that access /etc/hosts or /etc/passwd
are easy to develop."

How it works (3, Insightful)

Anonymous Coward | more than 7 years ago | (#18163626)

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 (5, Insightful)

amrust (686727) | more than 7 years ago | (#18163678)

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.

Please enter this captcha.. (0)

Anonymous Coward | more than 7 years ago | (#18164170)

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?

Re:How it works (1)

KDR_11k (778916) | more than 7 years ago | (#18163928)

I'd prefer if browsers didn't allow access to focus() at all because I can't think of a good reason to use it vs. lots of bad ones. If I want to focus something I'll give it the focus myself.

Re:How it works (0)

Anonymous Coward | more than 7 years ago | (#18163972)

Well for one thing it's the only way to print a selected window or frame.

windowname.focus()
windowname.print()

Re:How it works (2, Insightful)

ShieldW0lf (601553) | more than 7 years ago | (#18164106)

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.

Flaw is locale-dependent (1)

ESqVIP (782999) | more than 7 years ago | (#18164208)

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

old news (-1, Offtopic)

mortonda (5175) | more than 7 years ago | (#18163640)

My submission was rejected on the 13th.

Re:old news (0)

Anonymous Coward | more than 7 years ago | (#18163872)

Your comment would only be relevant if you thought the world was supposed to be fair.

Offtopic (1, Offtopic)

KeepQuiet (992584) | more than 7 years ago | (#18163642)

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

Re:Offtopic (1)

Joebert (946227) | more than 7 years ago | (#18163882)

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. (1)

jd (1658) | more than 7 years ago | (#18163992)

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:Offtopic (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#18164006)

at least it's not Kathleen Fent's vagina.

Interestingly enough... (0)

Anonymous Coward | more than 7 years ago | (#18163650)

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.

Oh really... (1, Troll)

Brad_sk (919670) | more than 7 years ago | (#18163658)

Firefox has a vulnerability... thats impossible!!...Lets blame it on windows as usual.

The real common vulnerability... (2, Funny)

NotQuiteReal (608241) | more than 7 years ago | (#18163686)

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:The real common vulnerability... (1)

jd (1658) | more than 7 years ago | (#18163974)

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

Re:The real common vulnerability... (0)

Anonymous Coward | more than 7 years ago | (#18164510)

you and 99.999% of open source developers. Huh, slashdot just shit all over my cookies, and now it wants me to log in. On a related topic, the captcha is "format c: | echo y"

Doesn't work with Firefox 2.0.0.1 on Windows XP (4, Informative)

Anonymous Coward | more than 7 years ago | (#18163704)

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 (1, Informative)

Anonymous Coward | more than 7 years ago | (#18163726)

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.

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

Ctrl-Z (28806) | more than 7 years ago | (#18163770)

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:Doesn't work with Firefox 2.0.0.1 on Windows XP (0)

Anonymous Coward | more than 7 years ago | (#18163806)

Yes, I have a boot.ini file that prints ok with "type c:\boot.ini" under an administrator command prompt. Also this copy of Windows XP is fully patched, and Firefox is default except for the Adblock Plus addon.

I'm curious... has anyone tested a modified version of this vulnerability with Firefox on Linux?

Re:Doesn't work with Firefox 2.0.0.1 on Windows XP (2, Informative)

SashaMan (263632) | more than 7 years ago | (#18164072)

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:Doesn't work with Firefox 2.0.0.1 on Windows XP (1)

jrumney (197329) | more than 7 years ago | (#18164464)

Beware captcha's and other form fields where you're forced to type a specific word or phrase.

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

nmb3000 (741169) | more than 7 years ago | (#18164082)

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. Full response. [slashdot.org]

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

Tim C (15259) | more than 7 years ago | (#18164138)

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

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

Lemm (88514) | more than 7 years ago | (#18164386)

Very true. First time I tried it, it got as far as c:bo and stopped cos I was typing too fast. That wouldn't be any use at all.

Mind you, the likelihood of people typing sufficiently slowly for this to catch the keystrokes is high enough to warrant this as a threat. However, that's only if the attacker knew the name of the file to look for. I guess to pull something from My Documents they just need the user to type in their Windows username (eg c:\Documents and settings\[username goes here]\My Documents - they could fill in the rest themselves), but then they'd have to append the document name, say, document1.doc to the end.

If they don't know the filename, this attack is dead in the water. Why would someone enter the name of a document on their system just because some random webpage asks?

I suppose a fix for this would be a warning prompt when a file is about to be sent. Any other suggestions? Is this solution too obtrusive?

Vulnerability doesn't work on Vista (Sort of) (2, Interesting)

Anonymous Coward | more than 7 years ago | (#18163740)

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

Re:Vulnerability doesn't work on Vista (Sort of) (1)

MichaelSmith (789609) | more than 7 years ago | (#18164052)

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.

Re:Vulnerability doesn't work on Vista (Sort of) (1)

funfail (970288) | more than 7 years ago | (#18164132)

Often when somebody prints out a document to distribute at a meeting they print the full path to the document
If the document is already distributed, what is the point of an exploit to download it?

Re:Vulnerability doesn't work on Vista (Sort of) (1)

MichaelSmith (789609) | more than 7 years ago | (#18164230)

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.

OT: CS:101 - Lost updates. (2, Informative)

TapeCutter (624760) | more than 7 years ago | (#18164300)

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

Try as I might... (2, Interesting)

oceanstream (1004835) | more than 7 years ago | (#18163798)

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:Try as I might... (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18164028)

Yes moron. If you had read the damned summary you would have read the words, "The vulnerability is not platform-specific, but these demonstrations are -- they work only on Windows systems."

Does using Linux preclude you from thinking as well?

Re:Try as I might... (1)

gordgekko (574109) | more than 7 years ago | (#18164038)

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

Re:Try as I might... (1, Insightful)

Anonymous Coward | more than 7 years ago | (#18164168)

Hey dumbass! The summary also says:

"The vulnerability is not platform-specific, but these demonstrations are -- they work only on Windows systems"

So he took the demos and tried to re-implement them to work on Linux and he couldn't get them to do so.

Re:Try as I might... (3, Informative)

nmb3000 (741169) | more than 7 years ago | (#18164096)

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

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

Sand boxing ? (1)

DrYak (748999) | more than 7 years ago | (#18164440)

Maybe the sand boxing is better and Firefox/Linux refuses that script have access to file that wheren't selected with a choose box ?

Sad realization (2, Funny)

Anonymous Coward | more than 7 years ago | (#18163816)

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

innerHTML (0)

Anonymous Coward | more than 7 years ago | (#18163832)

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?

Re:innerHTML (1)

SanityInAnarchy (655584) | more than 7 years ago | (#18164108)

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.

How does that even count? (1)

Zapotek (1032314) | more than 7 years ago | (#18163836)

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

Re:How does that even count? (0)

Anonymous Coward | more than 7 years ago | (#18164538)

<nitpick> You mean %SYSTEMROOT%\repair\sam </nitpick>

please someone (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18163838)

tag this love

Another vulnerability (0)

Anonymous Coward | more than 7 years ago | (#18163844)

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.

C:\ is my boot drive. (1)

Grinin (1050028) | more than 7 years ago | (#18163852)

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

Anyone else try Opera ? (2, Insightful)

Joebert (946227) | more than 7 years ago | (#18163912)

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:Anyone else try Opera ? (2, Interesting)

KDR_11k (778916) | more than 7 years ago | (#18163940)

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.

Firefox 2.0.0.2 + IE6 (1)

m-wielgo (858054) | more than 7 years ago | (#18163942)

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 (3, Informative)

pedrop357 (681672) | more than 7 years ago | (#18163958)

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 (1)

Mathinker (909784) | more than 7 years ago | (#18163960)

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 (4, Informative)

jesser (77961) | more than 7 years ago | (#18164066)

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:Variation on an old bug (1, Insightful)

slashdot.org (321932) | more than 7 years ago | (#18164378)

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)

erm, maybe because this is a fairly serious bug that still remains unfixed???

What about Konqueror? Or Safari? Or Opera? (3, Interesting)

Phil Urich (841393) | more than 7 years ago | (#18164094)

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

hmm (1)

nwmann (946016) | more than 7 years ago | (#18164114)

it's nice to know all the preview that shows up for firefox is c:\bo ... atleast if i type at normal speed

The vulnerability is called 'users' (1)

mrkitty (584915) | more than 7 years ago | (#18164166)

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.

Sharing (0)

Anonymous Coward | more than 7 years ago | (#18164188)

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

Offtopic rant (0, Offtopic)

n0rr1s (768407) | more than 7 years ago | (#18164206)

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.

Re:Offtopic rant (0)

Anonymous Coward | more than 7 years ago | (#18164220)

Personification is a perfectly valid literary and vocal device. Furthermore, words change in meaning over time, and you're the only person I've ever seen arguing that the word "enjoy" can only mean one thing.

Re:Offtopic rant (1)

Macthorpe (960048) | more than 7 years ago | (#18164420)

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.

Here one anoying bug (1)

jlebrech (810586) | more than 7 years ago | (#18164302)

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.

I thought this was fixed ? (1)

smoker2 (750216) | more than 7 years ago | (#18164318)

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.

Firefox 3 is unaffected (0)

Anonymous Coward | more than 7 years ago | (#18164416)

Why? Because you cannot manually type anything in file fields anymore. You have to use the Browse dialog.

Doesn't work here (1)

Arancaytar (966377) | more than 7 years ago | (#18164550)

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

QUERTZ keyboard not affected (1)

Arancaytar (966377) | more than 7 years ago | (#18164590)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...