Browser beware: Unpatched holes in Firefox, IE 7

Browser beware: Unpatched holes in Firefox, IE 7

Summary: Firefox and Internet Explorer users beware: There are serious, unpatched flaws in both browsers that could allow the manipulation of authentication cookies and the hijacking of files from your Windows machine.

TOPICS: Browser, Microsoft
Firefox and Internet Explorer users beware: There are serious, unpatched flaws in both browsers that could allow the manipulation of authentication cookies and the hijacking of files from your Windows machine.

Details on both vulnerabilities have already been posted to the Full Disclosure mailing list by Polish researcher Michal Zalewski. SecurityFocus provides coverage of the issue, which dates back to 2006.

According to Zalewski, a well-known hacker credited with several major flaw discoveries, there are two very different issues affecting Firefox and IE 7.

First up is a brand-new IE 7 bug that could be used to divert keystrokes from Web-based games, blog entries and comment forms, online chats. In certain scenarios, an attacker could exploit the flaw to read sensitive local files on a computer. "Some user interaction is required, but only to an extent commonly expected on some popular Web site. XSS attacks make it far worse," Zalewski said.

Click here for an online demonstration of the IE 7 (and prior) vulnerability.

Firefox 1.5 and 2.0 users can test for the flaw here.

Separately, Zalewski also warned about a new bug in the way Firefox handles writes to the 'location.hostname' DOM property. The bug could allow for the browser to appear as if were connecting to a bank, when in fact it would instead be receiving data from a bad guy, according to a note on the F-Secure blog.

Click here for a demo of the Firefox 2.0.01 bug, which requires JavaScript. Mozilla's security response team is already working on a patch.

I have a query in to Microsoft for a comment on the IE 7 issue. Will update as necessary. 

[UPDATED: February 15, 2007; 6:17 PM Eastern]  Just received this note from the Microsoft Security Response Center:

Microsoft's initial investigation reveals that an attacker could gain access to user files if the location of a given file is already known. In order to be successful, an attacker in advance would have to convince the user to enter the location of a file into an attacker's Web page through social engineering.  Upon completion of this investigation, Microsoft will take appropriate action to help protect our customers.

Topics: Browser, Microsoft

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Doesn't even work

    I even put a fake boot.ini file in the c:\ directory because Vista doesn't have boot.ini. It was not able to read the contents.
    • That's strange

      All three demos worked for me on fully patched IE 7 and FF 2.0 (XP SP2).

      Ryan Naraine
      • I'm on Vista, I think protected mode broke it

        I know Vista doesn't have a boot.ini, so I put a bogus with with message in it to see if the exploit will display the contents of my message. It still didn't work even though I had full read/write permission to the boot.ini file. I'm thinking since IE runs in a reduced privilege mode, it can't get to that file. If that's the case, Protected Mode did its job.
        • My Vista has a boot.ini file!

          My installation of Vista DOES have a BOOT.INI file... This is because I have a third-party driver that needs it to load (this tool still does not install in the new Boot manager, but loads sometime during the boot; I think it will be fixed later in a future release for Vista, to get better security protection, because the BootManager files are severely protected).

          Vista still interprets BOOT.INI when it is present within its boot loader (but I don't know exactly when it does that; I think that it may first validate it using some security checks when the file is created; and I think/hope that Vista checks that the referenced files are effectively not tampered since the time of installation, using for example MD5 and SHA-1 checksums, or the now recommended SHA384 or SHA512 checksums).

          I guess that BOOT.INI is interpreted during boot to allow making some changes of boot options. However, it can't be used to change the boot image for the boot loader.

          Note that before the booloader, there's a preboot loader stored in the first few sectors of your harddisk, even before the partition table. This code is where the bootmanager gets loaded: it checks the state of the partition table, then if it detects a NTFS partition, it looks for the pre-Boot loader and loads it; This preboot loader then launchs the boot manager, that will first checks its own security (by looking for the precomputed and digitally signed checksums of the partition table, and of the prebootloader and of the BIOS image). But this is still where it can be fooled by some "smart" malware, or by a virtualization system...
          • Processor security check

            Vista seems to include a processor security check:
            it won't even boot from the harddisk, even if no data was changed on disk, if the processor type has changed since last boot.
            This is not a licence check, but apparently a security check against attempts to block so processor security feature.

            This is now a serious issue for the future of your system: if you have some damaged critical device, and you need to change tour motherboard, you'll need to use a motherboard with a processor of the same category.

            Trying to reuse your existing harddisk to place it in a replacement PC will simply not work. The issue already existed in Windows XP, but it is more serious now. The biggest problem is that, in case of serious damage, you'll need to find replacement products which may no more available in normal sales circuits, so you'll need to recover using recycled products.

            If you want to be secure, this recycled product will need to have been controled, so the recycled replacement will be even more expensive than a fresh new and more performant product, because it will use specialized distribution circuits.

            This also applies to full-system archives: they are not usable if your system annot be fully reconstructed after a severe hardware failure. This is a serious problem for managing software licences, because this "no-reinstall" issue means that you'll need to make full installations on a replacement system, and then look for a way to recover your data (unfortunately, the licences are not transferable, and Windows does not offer any way to transfer the licences you have from an old harddisk that stored a previous installation, as it requires a live system with a secure registry service to make suych transfer possible).

            So beware of your licences: don't assume tht they are safe when stored by the operating system. Keep separate archives of them, and make sure you don't create any personal data of files within critical system areas. Nothing should depend, in your installation about what you have in your registry or in the encrypted hidden storage managed on disk by Windows, as this data is not usable elsewhere.

            In other words: keep a separate archive of all your downloaded installation files, avoid all "live" installations (which may be no longer available in the future if you need to restore your system from scratch). Keep your licences received in email in a separate archive (don't think that your Office Outlook .PST files or Outlook Express database files will be usable in the future to recover them!)

            Really, Windows needs a severe cleanup to allow storing user data and licences in a safe place that can be correctly backup. The system backup in Windows is a nightmare and does not save all what will be needed to reover your system, because archives are only usable as an unseparatable whole!

            We don't have so much issues with Linux/Unix, because you can archive everything, and also use the archives later in a more fine subselection to explore them and restore just what you need.

            Then I spoke about system security at boot time, but the fact that this can be so easily tampered by application software like IE7 and live unsecured data sources like the Internet is a serious issue.

            Really, the OS should be an unbreakable blackbox where no user data or private licence is allow to be stored into. Unfortunately, with the intrusion of DRM in Windows (and even more and everywhere with Vista), even private data is hardlinked to the system where it lives, and this places your private data at severe risks in the future, in case of system crash.

            Microsoft has chosen the wrong model for its DRM: it is hardwired to the hardware where it is installed instead of being wired to a verifiable user identity, independantly of the hardware that he currently uses. The "one system only per user" licencing is violating all basic security rules, and violates all legitimate consumer rights. And it is a severe risk for every company data infrastructure.

            Conclusion: don't use Windows for your critical private data you need. Use systems that offer security based on verifiable user identity, and not on any hardware signatures.
          • I changed processors and it works fine for me

            I changed processors and it works fine for me so I don't think you have that right.
          • Are you serious?

            Are you saying I would not be able to access my Outlook data files after a reinstall of Vista on a new, different machine? Surely that's not possible: even MS wouldn't be that stupid! Seriously though, what's the truth about this because I am very worried about changing to Vista. I am seriously considering changing OS and this would certainly be a big push if it is really true.
          • No, it's not true

            I've already changed my processor in Vista and it's fine. I also migrated my old Outlook data from 2003 to 2007.
  • Didn't work for me (XPSP2, IE6)

    The browser was not able to read my boot.ini, and I figured out why. I log on as a [b]limited user[/b] in XP, and don't have access to it.
    • Yeah, I think the story said the exploit was for IE7 also. :PPP

      • (nt)It's supposed to work on IE6 too

    • Works on XP, SP2, FF

      It worked on my system, XP, SP2, FF I didn't even finish typing the entire string. As soon as I started to type the word "Incdientally" it pulled up the boot.ini file. I guess that's one more reason to spend more time on the two Linuz machines I've been playing with. I need to test FF on the Ubuntu machine and see what happens.
      • It did not work in Suse using Firefox 2

        I have not tried it on our Windows machine yet
        • duh

          There's no c:\boot.ini in linux

          I'm sure the exploit could be crafted to work in linux
  • FF extensions help

    I've got NoScript running, among other extensions, on my copy of Firefox, and neither demo worked. I'm not saying that it would be impossible for me to get hacked, but it would probably involve visiting a whitelisted site that has recently been compromised--possible, but the risk is pretty low.
    • noscript prevented it

      noscript seems to have stopped it.
      • noscript rulez :)

        Well, that's the idea. Sure it will prevent the script from running. Just change the setting to "temporary allow" and it will work.
  • Sad to say, it worked for me.

    My boot.ini file was displayed after I typed in the text as instructed - not a very encouraging thing to discover. The question is: is any browser really 100% safe?
    • RE: Sad to say, it worked for me.

      Which Browser?

      I tried it with Firefox with noscript, and the exploit failed.
    • Failed on IE7 in Vista