Firefox exploit found in the wild

Yesterday morning, August 5, a Firefox user informed us that an advertisement on a news site in Russia was serving a Firefox exploit that searched for sensitive files and uploaded them to a server that appears to be in Ukraine. This morning Mozilla released security updates that fix the vulnerability. All Firefox users are urged to update to Firefox 39.0.3. The fix has also been shipped in Firefox ESR 38.1.1.

The vulnerability comes from the interaction of the mechanism that enforces JavaScript context separation (the “same origin policy”) and Firefox’s PDF Viewer. Mozilla products that don’t contain the PDF Viewer, such as Firefox for Android, are not vulnerable. The vulnerability does not enable the execution of arbitrary code but the exploit was able to inject a JavaScript payload into the local file context. This allowed it to search for and upload potentially sensitive local files.

The files it was looking for were surprisingly developer focused for an exploit launched on a general audience news site, though of course we don’t know where else the malicious ad might have been deployed. On Windows the exploit looked for subversion, s3browser, and Filezilla configurations files, .purple and Psi+ account information, and site configuration files from eight different popular FTP clients. On Linux the exploit goes after the usual global configuration files like /etc/passwd, and then in all the user directories it can access it looks for .bash_history, .mysql_history, .pgsql_history, .ssh configuration files and keys, configuration files for remina, Filezilla, and Psi+, text files with “pass” and “access” in the names, and any shell scripts. Mac users are not targeted by this particular exploit but would not be immune should someone create a different payload. [Update: we’ve now seen variants that do have a Mac section, looking for much the same kinds of files as on Linux.]

The exploit leaves no trace it has been run on the local machine. If you use Firefox on Windows or Linux it would be prudent to change any passwords and keys found in the above-mentioned files if you use the associated programs. People who use ad-blocking software may have been protected from this exploit depending on the software and specific filters being used.

224 comments on “Firefox exploit found in the wild”

  1. Olivier wrote on

    – Mozilla: “Disable Flash, it has so many security flaws!”
    – Me: “Uninstall Firefox, it has so many security flaws!”

    1. Cadeyrn wrote on

      There is no browser without security flaws. Important is how fast Mozilla (and other browser developers) provide updates and communicate the security flaws.

      Thanks Mozilla.

      1. Olivier wrote on

        Same regarding Flash.

        Thanks Adobe.

        1. Dolfje wrote on

          Though Mozilla is releasing and communicating a little bit faster than Adobe. (1 day vs 2 weeks)

          1. Jeff wrote on

            Adobe released their patch 2 days after the last major exploit was discovered.

            Lying and saying “2 weeks” is a bit libelous, especially over a topic as serious as this.

            1. Nerull wrote on

              If only there were a long history of serious flash exploits to choose examples from

            2. Leo wrote on

              The LAST major exploit. But many others before it took a lot of weeks to be fixed.

            3. E wrote on

              Tough to understand you with Adobe IN YOUR MOUTH

            4. E wrote on

              MY BAD..I meant @ Jeff

              SAME COMMENT though..LOL

        2. Anon wrote on

          Flash ? Are you an archaeologist ? 😀

          1. UncleBubba wrote on

            No; he’s a troll, going for the cheap shot without contributing anything useful to the conversation. Just ignore him.

          2. Andrea Giammarchi wrote on

            haha, came here for this: not disappointed!

          3. Olivier wrote on

            I’m coming from the future:
            – Flash is still awesome there
            – Firefox still has its memory leaks since its first version
            – Firefox still hasn’t implemented “input type date”
            – …


            1. Pablo Cholaky wrote on

              Flash doesn’t support Linux anymore, so, yeah, remove Flash and update Firefox is fine

            2. Olivier wrote on

              That’s so wrong to say Flash doesn’t support Linux anymore: Adobe has updated Flash on Linux at the same time as Flash on Windows and OS X.

            3. felipe wrote on

              input type date is one of the first thing that I hated about Firefox when I started to develop web pages, cause I was too noob for include a jquery date picker. Now I hate that firefox does not have a Toggle Device Mode like Chrome. But it render my web site more faster than chrome.

        3. TFerguson wrote on

          Yes, Thanks Adobe for all of the animated advertising provided by Flash. Just can’t live without it!!!

          1. Olivier wrote on

            The problem isn’t Flash, but advertising: you really should block ads, like all sane person do.
            People install antiviruses when they need in priority an ad blocker (ex: the yahoo ads campaigns from a few days ago which was distributing malwares).

            1. Peter Bindels wrote on

              You would almost say that placing other people’s random code snippets on your web site for pennies on the dollar is a bad idea for your users.

      2. Jones wrote on

        @Cadeyrn: Yes, software will have flaws. That’s why it’s important for Firefox to include as little software as possible. That’s why something like pdf.js shouldn’t be provided by default. It should be something that the user must install and enable on his or her own.

        Other unnecessary parts of Firefox, like Pocket and the advertisements shown on the default page, should be removed, too.

        Recently, Firefox’s attack surface has been getting bigger and bigger thanks to all of this junk that’s being included in it. The Firefox developers need to put a stop to this, and need to start reversing it, in fact!

        Get rid of pdf.js! Get rid of Pocket! Get rid of the advertisements! Get rid of any and all code like that that’s totally unnecessary.

        Firefox should be a very minimal browser that we extend as we need to. It should not come with anything that we could install separately!

        1. Olivier wrote on

          I concur with this statement. I think that Pocket should be a browser extension instead.

          While I think that the inclusion of pdf.js is not a bad idea, it shouldn’t have special file access privileges that could lead to vulnerabilities like this one.

        2. Emanuel Hoogeveen wrote on

          The advantage of pdf.js is that it runs purely in Javascript, so if Firefox’s Javascript engine (and DOM) is secure, it will be secure. Opening a PDF in a separate program just shifts the security concerns over to that program, which just adds to the attack surface. The only questionable part about this is that the embedded pdf loaded automatically rather than presenting the user with a prompt or being click-to-play – but IIRC the same thing would have happened with the Adobe Reader plugin people used to use (could be wrong though, it’s been years).

        3. Daniel Veditz wrote on

          Including our own PDF Viewer is an honest attempt to protect our users, the vast majority of whom otherwise end up using outdated versions of Adobe Reader which has been and still is actively exploited. If you prefer a more full-featured PDF Viewer and know you keep it secure feel free to go to about:preferences#applications , scroll down to PDF, and change it from “Preview in Firefox” to automatically save or open in the application of your choice.

        4. firefox_fan wrote on

          I agree Firefox is coming with too many unwanted things ! which is making it bloated, :'(
          pocket, the hello! feature. Totally not required.

      3. MJ wrote on

        It would be nice to believe this is actually “New” as its being said, but I fear thats far from the truth.

        This is just the first incident, where the exploit was discovered and made public, there is no real way to tell how long its been around or how long anyone has known about it.

        I tend to believe, with the vast amount of knowledge and tools available to developers in this day and time, these type incidents should never happen, but that would probably only be true in a perfect world.

        I do hope the developers out there are starting to take the true sense of the word “Security”

        1. JJ wrote on

          “[…] there is no real way to tell how long its been around or how long anyone has known about it.”
          Firefox is open source, which means you can find the date the bug was introduced by yourself.

    2. Barry Allen wrote on

      Oliver: “Uninstall Firefox, it has so many security flaws!”
      Me: “Don’t use computers, they have so many security flaws!”

      1. Ramon (Not Cisco) wrote on

        Nice one, fastest man alive

      2. human robot wrote on

        Humans are the worst security flaw there is….

        Don’t click that!!!!!

    3. Anonymous wrote on

      Nice PR Stunt, Microsoft?

    4. Katz wrote on

      Thank you! Their hypocrisy on this matter is astonishing. The disabling of Flash was nothing more than a PR stunt to try and move more people to the turtle-speed HTML5 that has less than half the necessary features by specification and much fewer in implementation.

      1. Nerull wrote on

        Disabling a known vulnerable version of something that is being actively exploited through major ad networks and silently installs cryptolocker – PR STUNT!

    5. Robert O’Callahan wrote on

      We didn’t ask users to disable or uninstall Flash. We just lightly blocked the vulnerable version until it was updated with the fix. (“Lightly blocked” since you could still click-to-play.)

      Also the situation with Flash was a lot more serious since the exploit was available to absolutely everyone in the world via the Hacking Team data dump.

    6. Behrang wrote on

      > Mozilla: “Disable Flash, it has so many security flaws!”

      It is not only Mozilla that is encouraging users to disable Flash. The whole industry is (with the exception of Adobe I guess).

    7. tpimh wrote on

      Anyway Flash is so outdated now. Starting with Firefox 42 it is built with GTK3 and Flash Plugin still uses GTK2 for user interface. There is no way to support it.

    8. Java wrote on

      Read it again people! Its not Flash its Java!

      Don’t install Java and most issues with not be an issue!

      1. Java wrote on

        Don’t install Java and most issues will not be an issue!

  2. Vasya wrote on

    What was the news site where the exploit was shared? I want to estimate my risks.

    1. Sergei wrote on

      Since that was an ad that contained the exploit, it could be on any news site and elsewhere. Consider the wost case scenario: your data leaked. Change passwords as recommended.

      1. JJ wrote on

        A very good reason to block ads…

        1. Java wrote on

          I have to agree with you

        2. AZ wrote on

          …and use NoScript!

  3. RB wrote on

    So mozilla? Perhaps good that windows 10 protects it’s users by default from using firefox?

    1. Java wrote on

      Only if you like all thing Microsoft jammed down you throat

  4. Alexey wrote on

    Please publish the site address as soon as possible!

    1. tpimh wrote on

      It was on multiple sites, because the malicious code was distributed by ad network.

      1. rn10950 wrote on

        Does this mean that ABP or uBlock users are safe?

        1. mat2 wrote on

          nope, the domain was not detected by these programs

  5. Jonathan wrote on

    If the files are stored on an encrypted drive, would the exploit pull obfuscated data or human readable data?

    1. ernesto wrote on

      If the drive is “mounted”/opened (if you have entered the password), that is if the files are accessible e.g. in the Windows Explorer, then human readable data would be uploaded. (Otherwise the files couldn’t be found at all.)

  6. DAX wrote on

    So it doesn’t affect users who chose not to save passwords, right?

    1. Daniel Veditz wrote on

      The exploit payload did not go after Firefox profile data, but the data from other programs. For example, if you use an FTP program you might configure it with passwords for the servers from which you regularly download files. For a developer the most concerning ones might be the .ssh files and the _history files which can contain passwords or other sensitive data from commands entered on the command line, even if you didn’t intend to have the password saved anywhere.

      1. DAX wrote on

        Oh, this is how it works. Thanks.

  7. Oliver wrote on

    Let’s make it an opportunity to remind you people that, while firefox won’t store your passwords in plain text, plenty of other programs will do, such as Filezilla (the “and site configuration files from eight different popular FTP clients” reminded me of it.)

    1. ls wrote on

      If you don’t use a master password it has to store them as something equivalent to plain text though, no?

  8. Jonas Lejon wrote on

    Is the Tor Browser Bundle vulnerable?

    1. Khannie wrote on

      Very interested in this.

      Also I would like to know how the user discovered that the exploit was being run.

      Lastly I would like to know how the exploit worked.

      Thank you.

      1. chasm22 wrote on

        Go to Hacker News. Read the comments(many) after the story concerning this bug. The person who discovered the bug has posted quite a few times, including answering many inquiries. It’s a very interesting read. The person only discovered the bug after the exploit was found running on his machine. The comments on also interesting because of the numerous ideas being discussed as to how to avoid this type of exploit.

    2. fukusa wrote on

      Does it include PDF.js? This exploit uses a vulnerability in PDF.js.

      1. Jonas Lejon wrote on

        Yes. Tor Browser Bundle include pdf.js

    3. Nysepho Andar wrote on

      Maybe not. As far as I’m aware, NoScript in Tor blocks everything by default.

      1. James Edward Lewis II wrote on

        The Tor Browser actually allows all sites by default to run scripts, even though it does bundle NoScript; you have to deliberately go back to default-deny, which is what NoScript does on ordinary builds of Firefox.

  9. Ray Radlein wrote on

    If you have PDFs disabled (via an extension or otherwise), would this still affect you?

    1. Daniel Veditz wrote on

      The exploit requires the PDF Viewer built into Firefox to trigger the vulnerability. If you have disabled PDFs or are using an external program to view them then this would not affect you. You would, of course, have to worry about potential security vulnerabilities in whatever program you were using so make sure you keep that updated!

      The only other code we know of that might (might!) combine with the underlying flaw in a vulnerable way is Shumway, which is 1) not shipped by default, 2) currently has the feature in question disabled, 3) the functionality may not be reachable from content in a way that could be exploited, and 4) certainly would not be affected by this exploit which quite explicitly triggers the PDF Viewer. In any case, since we fixed the underlying vulnerability in 39.0.3 anyone testing a pre-release version of Shumway no longer has to worry about even the remote possibility.

      1. Steve wrote on

        I’ve seen a few references saying having pdfjs.disabled = true would have been required for mitigation, but also some saying that using alternate readers, or using ‘Always ask’ to handle PDF content, is sufficient. If I use ‘Always ask’, but did not have pdfjs.disabled set, do I need to worry?

        Thanks for your efforts in keeping Firefox secure, they’re much appreciated.

  10. Keanzu wrote on

    Thanks for the fix, I’ll be sticking with Firefox.

  11. Marcello Romani wrote on

    Form me the takeaway from this is: download PDFs to disk and open them with a “normal” PDF viewer program.

    1. Daniel Veditz wrote on

      That can be even riskier unless you are diligent to keep up with security fixes in that other PDF Viewer. For the average Windows user sticking with the always-updating built-in Firefox viewer is far, far safer. But if you know how to manage your own security that’s a perfectly valid choice.

      1. KX wrote on

        However, one consideration is that pdf.js is heavily integrated into Firefox itself and can be triggered with as little as one click. With downloading to disk and viewing from there with a seperate program, one is purposefully verifying that that is the PDF that they want to view and not trusting a browser integration that increases attack surface. Up until that point the PDF is just a binary blob.

        The severe problem with this level of integration is that you start automating too much and not verifying enough with the user: “Do you want to open this document?”. pdf.js does nothing to verify that the user is really desiring that document to be opened.

        Mozilla may be able to maintain pdf.js, but is Mozilla maintaining a limited attack surface so users are protected? Part of security is being proactive and restricting the manner exploits may proliferate, not just updates, updates, updates.

  12. Ollie wrote on

    Could you share some unique strings transferred over the network by this attack? (E.g. from the js code.)

    This way people who have a pcap record of their network traffic could determine whether they were targeted.

    (I’m assuming here that the data extractor encodes the payload somehow, so looking for my passwords in the pcap won’t help.)

  13. myf wrote on

    Could that exploit have worked even with `pdfjs.disabled;true`?

    1. RaphAstronome wrote on

      I am not sure but I think not because if pdf.js is disabled the PDF files will be downloaded instead of displayed by FireFox.
      So, if you open it with an other PDF reader you shouldn’t be concerned by this flaw.

      But upgrade FireFox when possible, it is safer.

    2. fukusa wrote on

      Simply, no.

  14. horst wrote on

    Am I affected by this if I set firefox to “always ask” for PDF files?

  15. VVSite wrote on

    Why You don’t publish name of this news site? I can’t check browser history and instruction to change all my passwords drives me crazy >:(

    1. JJ wrote on

      Read the comments… The exploit was served by an ad.

      1. mat2 wrote on

        The exploit was not served by an ad network. This is a description from the original reporter:

  16. alp wrote on

    Can you point to commits fixing this issue? Is it or something else? I’d like to try porting it to ESR 24….

  17. bill wrote on

    We receive since a couple of days an increasing amount of on-the-fly encrypted javascript trojan variants via spam mail, mostly originating from ukraine. Maybe the same. Is Thunderbird affected as well?

  18. Anonymous Coward wrote on

    IMO a very smartly targeted exploit – hunts for passwords. If you gather credentials for github, cloud store services and whatnot from ,many-many people, you’re in a way better position to start harvesting confidential data from the web than if you just crawl their local drives.

  19. zeus wrote on

    I had in about:config pdfjs.disabled set to true and pdfjs.previousHandler.alwaysAskBeforeHandling set to true. Was I protected from this security exploit?

  20. esh wrote on

    “.. and site configuration files from eight different popular FTP clients”. Which FTP clients? Can you name it?

    1. vinc17 wrote on

      I don’t know these “eight different popular FTP clients”, but under Linux at least, all software that uses the .netrc file (which is not encrypted). This includes netkit-ftp, lftp, curl and wget.

More comments:1 2 3 5