Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Bug Internet Explorer Mozilla Security The Internet

IE and Firefox Share a Vulnerability 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."
This discussion has been archived. No new comments can be posted.

IE and Firefox Share a Vulnerability

Comments Filter:
  • by varmint jerky ( 810306 ) on Tuesday February 27, 2007 @12:57AM (#18163574)
    Next thing you know they'll be coquettishly batting eyelashes at each other and accidently eating the same strand of spaghetti.
    • Re: (Score:3, Insightful)

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

        by 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.
        • by Qzukk ( 229616 )
          Actually, the firefox one "worked" on Linux, it just tried to upload C:\boot.ini which obviously didn't work.
      • by Anonymous Coward
        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
  • Nope (Score:4, Informative)

    by The Bungi ( 221687 ) <thebungi@gmail.com> on Tuesday February 27, 2007 @01:01AM (#18163606) Homepage
    Not Firefox 1.5x under a non-admin account on XPSP2, though I admit that setup, while sane, is unfortunately not really common...
    • I could not make it work under such system either. Maybe it needs more ? Something which is not enabled on my firefox ?
    • Re:Nope (Score:5, Interesting)

      by TheLink ( 130905 ) on Tuesday February 27, 2007 @01:16AM (#18163690) Journal
      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).
      • >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: (Score:2, Interesting)

        by Anonymous Coward
        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?
        • it would be nice if google would ask for permission to upload the file.
          and it would be nice for mozilla to confirm "silent submit" with file inputs ....

          i was wondering on the same issue a few days ago, how can they protect this from happening, right now, they can't .... but mozilla should fix it.
      • by acidrain ( 35064 )

        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.

        • by cp.tar ( 871488 )

          Naq vs lbh znxr gur glcvat ghgbe ebg13 rirelguvat gur fhpx^U^U^U^Uhfre unf gb glcr, lbh'er nyy frg...

      • "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 (Score:4, Insightful)

          by TheLink ( 130905 ) on Tuesday February 27, 2007 @05:42AM (#18164792) Journal
          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: (Score:3, Informative)

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

          • by gkhan1 ( 886823 )

            In virtually all modern linux-systems, nothing really sensitive is stored in /etc/passwd, all the good stuff is in /etc/shadow (which is only readable by root). This is called shadowing. And by the way, you never store a password, you only store a salted hash of it.

            Run the command "cat /etc/shadow" and then run "sudo cat /etc/shadow" and watch the difference. So, unless you are running firefox as root (why, oh why, are you running firefox as root?!?!?!?) you'll be pretty safe.

            • by Phisbut ( 761268 )

              In virtually all modern linux-systems, nothing really sensitive is stored in /etc/passwd, all the good stuff is in /etc/shadow

              I know all that, which is why I said that I don't know why I would fear exposing my /etc/passwd file.

              So, unless you are running firefox as root (why, oh why, are you running firefox as root?!?!?!?) you'll be pretty safe.

              Because I miss my good old days of running Windows with IE?

      • by joshetc ( 955226 )
        So basically your setup is more secure than most US government workstations?
    • by donaldm ( 919619 )
      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.
      • Comment removed based on user account deletion
        • by cp.tar ( 871488 )

          Oh, yes, with shadowing enabled (and who doesn't enable it?) they're going to have real fun with my /etc/passwd.

          • Re: (Score:3, Informative)

            by 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.
          • Comment removed based on user account deletion
            • by cp.tar ( 871488 )

              Well, that is true... OTOH, first they'd have to see which daemons are running (in my case, none, since I don't have any servers).
              Then they'd have to hope that the brute force attempts aren't discovered in time or the forced accounts automatically disabled after a certain number of attempts and that the attempts themselves aren't logged.

              All in all, that's quite a lot of hope.

              One of my computers has a guest account: login is username, password is password.
              There you go, attack it. Knock yourself out.

    • Using Firefox 1.5.0.10 here and the demo's only semi-working. I typed what it said exactly and all it showed was "C:\bo". While it's not good that it managed to pick up any of it, working intermittantly like that isn't going to be doing any attackers any good. I wonder if the script's screwing up if you type too fast or something.
    • by LordEd ( 840443 )
      Under this setup, does it work under IE?
  • How it works (Score:3, Insightful)

    by Anonymous Coward on Tuesday February 27, 2007 @01:07AM (#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 (Score:5, Insightful)

      by amrust ( 686727 ) <marcrust AT gmail DOT com> on Tuesday February 27, 2007 @01:12AM (#18163678) Homepage

      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.
    • by mgiuca ( 1040724 )

      It doesn't sound like this would be particularly exploitable because you'd need them to type the letters in the right order

      This is true, but say you put it on a website where people type a lot into a text box - such as a forum, or web mail, or ... AAAH! SLASHDOT!

      It turns out that some percentage of users will probably type the correct string just by chance (hence the reason why the sample page used that silly expression about cheese).

      Another way they could trick you into typing the letters in the correct or

  • by NotQuiteReal ( 608241 ) on Tuesday February 27, 2007 @01:14AM (#18163686) Journal
    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...

    • by jd ( 1658 )
      I think I met a regular user once. I'm not entirely sure, though, as they seemed rather odd.
    • by LordEd ( 840443 )
      The TFA says the bug is not OS specific. Linux users aren't usually 'regular users'.
  • by Anonymous Coward on Tuesday February 27, 2007 @01:18AM (#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.
    • by 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: (Score:2, Informative)

      by 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.
      • by jrumney ( 197329 )
        Beware captcha's and other form fields where you're forced to type a specific word or phrase.
    • by 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

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

      • "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
  • Try as I might... (Score:2, Interesting)

    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?
    • Who modded this guy insightful? The summary says it's common to IE and Firefox running on Windows.
    • Re: (Score:3, Informative)

      by nmb3000 ( 741169 )
      Did I miss something from TFA that makes this windows-specific?

      I think the presence of a C:\ might help.
    • Maybe the sand boxing is better and Firefox/Linux refuses that script have access to file that wheren't selected with a choose box ?
    • by smiggly ( 235904 ) on Tuesday February 27, 2007 @06:44AM (#18165088)
      It just takes a few changes. Try this:

      http://www.thanhngan.org/fflinuxversion.html [thanhngan.org]
    • At the end of this post, the PHP code for a Linux version (whitch uploads crontab).
      - 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
  • by Anonymous Coward
    So...Safari on the Mac is A-OK?
  • by Joebert ( 946227 ) on Tuesday February 27, 2007 @02:13AM (#18163912) Homepage
    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: (Score:2, Interesting)

      by 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.
    • I'm running Opera 9.20, build 8713 on Windows XP. When I tried the IE version of the bug, the page automatically turned to:

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

      When I try the Firefox version, it just won't go on to the following page at all. Then I tried it in IE7 and Firefox to see what

  • Requires javascript (Score:3, Informative)

    by pedrop357 ( 681672 ) on Tuesday February 27, 2007 @02:29AM (#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.
  • by jesser ( 77961 ) on Tuesday February 27, 2007 @03:06AM (#18164066) Homepage Journal
    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: (Score:2, Insightful)

      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???
    • Re: (Score:3, Insightful)

      by 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?
  • by Phil Urich ( 841393 ) on Tuesday February 27, 2007 @03:13AM (#18164094) Journal
    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?).
  • 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.
  • You should disable javascript, yet again.
  • 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.
  • 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 differ
  • 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.
  • And that kids, is what happens when you don't use condoms. Firefox should have known better.
  • Comment removed based on user account deletion
  • IE7, Firefox2, Opera9, Konqueror and Safari share a vulnerability: Javascript.
  • Firefox obviously violates M$ IP if there is a shared venerability.
    • by Tim C ( 15259 )
      Unless it's an unintended consequence of one (or more) of the relevant specs, or it's in a third-party library that both browsers happen to use.
  • ... 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?
    • exactly, i mean, not to sound like flamebait, but you think people would have moved on to Opera by now, but yet it still remains LARGELY ignored (how often do you hear about opera vunerabilities?)
    • > I can not but wonder why FireFox is considered to be a secure browser. It seems to have more security issues than IE lately

      0. "seems to have" doesn't sound very scientific proof.

      1. Each security bug in Firefox is revealed and count as one, in IE not all are revealed (mostly only if they are public already) and often several have been counted as one by Microsoft. And most like Microsoft is not the only one. Opera didn't reveal the security bug it fixed untill a long time after the version had been relea
  • 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 ar
  • That both browsers are mature enough to share.
  • 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.

You are always doing something marginal when the boss drops by your desk.

Working...