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. YourMother wrote on

    Since you made a big fuss over Flash’s security vulnerability only weeks ago, blocking the plugin until users updated it, shouldn’t you be blocking access to websites until users have updated Firefox?

    1. Roy wrote on

      Firefox MUST block firefox! :p

  2. joão lopes wrote on

    why does firefox has a pdf viewer? that is just bloat and, also, completely nonsense. if one wants to see a pdf document, one downloads it and opens it with some pdf reader. a browser is a browser.
    instead of useless buggy pdf readers, firefox should support, for example, the mng file format. also, bring back the feed icon on the address bar.

    1. James Edward Lewis II wrote on

      It maintains a PDF reader (much like Chrome and Edge bundle their own PDF plugins, except Firefox uses JS rather than a plugin) because people expect to be able to read PDF files in their browsers; this expectation has been there for two decades, ever since someone at Adobe figured out how to hack Netscape to load Adobe Reader, and then Netscape liked the idea and formalized it as NPAPI.

      1. Manly Electronics wrote on

        Did you want to say, Firefox includes but does not maintains a built-in PDF reader? That is the reason why hackers targeted it. It still has other issues like slowness or even inability to read large PDF files (compare to Chrome PDF reader), very slow search feature. Basically Firefox PDF reader is useless and annoying if left by default accidently.

    2. Daniel Veditz wrote on

      It was not very long ago that PDFs were perhaps the primary vector for malware attacks. Everyone had Adobe Reader and it was almost always old because updates were manual (or maybe they just didn’t work very well). Adobe has since fixed the update mechanism, but in the meantime all the browsers incorporated alternate PDF Viewers to protect their users. Irony, eh? The exploit scoreboard still favors the built-in PDF Viewer, however.

  3. francois wrote on

    How come they didn’t target sync storage key and firefox’s own password database ?

    1. stoyan wrote on

      Because what they need is access to hosting accounts where they can upload malicious content.

  4. Dmitry wrote on

    Are you mean the Adobe Acrobat PDF plug-in, or an other (internal, built-in) PDF viewer?
    If the second, – what versions of Firefox have the such vulnerable built-in PDF viewer?

    Is Firefox 15.0.1 with the disabled Adobe Acrobat plug-in vulnerable? Or maybe better enable Acrobat plugin to prevent usage of internal Mozilla’s PDF viewer?

    1. James Edward Lewis II wrote on

      The problem is in PDF.js and what you should do is update your copy of Firefox and keep using that internal renderer; if you’d rather not do that, consider an alternative PDF plugin, like PDF-Xchange, because Adobe Reader, while it has gotten much more secure since X (now it’s at XI and DC), is still bloated compared to alternatives.

      I don’t know whether Foxit has gotten a 64-bit plugin yet, but I know that PDF-Xchange does, and Reader just got one with DC (but be sure, if you do use Reader DC, that you read up on how to disable all those upsells).

  5. Chuck Baggett wrote on

    Is there really no record in Windows and no way to make Windows keep a record of what files are uploaded to where?

    1. Daniel Veditz wrote on

      There are all kinds of monitoring tools people may have previously installed that would catch evidence. But those aren’t standard and you can’t install them after an attack to get retroactive data.

  6. Gerard Braad wrote on

    Running Firefox inside a sandbox could mitigate most, if not all, of the problems of the browser accessing files it should not be able to.

    SELinux sandbox or Firejail are some of the examples

    These solutions are less heavyweight than resorting to full virtualization when using a VM. Although, the mentioned examples only work on linux.

    1. Dmitry wrote on

      But how about Windows versions of Firefox?

      1. Gerard Braad wrote on

        For Windows you have firewall applications (e.g. Kaspersky internet suite) which also monitor disk access behaviour and based on this you can allow or disallow the access. There is a tool such as sandboxie; which got good reviews

        However, most users will just allow the access for these applications and have trained them to do read-access without prompting the user anymore. It really depends on the tool you use and the ruleset you have…

    2. Gerard Braad wrote on

      SELinux would not have prevented this as Firefox would run in your users context (unconfined_t), The alternative is, the sandbox command:
      And firejail as mentioned is at:

  7. Christoph Anton Mitterer wrote on

    Not that I’d be much surprised as Mozilla gives typically a shi* about security…. but this raises once more the question:

    Why does Firefox (or some browsers) in general try to be (nearly) whole OSes?
    Containing a PDF viewer is just plain stupid and software bloat.

    If people want to view PDFs, they should download these files and open it in an appropriate viewer…

    1. Daniel wrote on

      Because people (wrongfully) believe the Web to be a great application platform and a place to experience “rich media” instead of text-based documents with perhaps some stylization to make the reading experience better.

      Before Javascript, there basically weren’t any security exploits in browsers. The core (HTTP, HTML, CSS) despite being clunky and legacy, works well and is stateless, preventing any such issues as the ones we’ve been seeing for years.

      I really wish Web users would wake up to the reality that they’re misusing the technology.

      1. Hervé wrote on

        Browsers before JavaScript were prone to a lot of crashes, leading to stack overflow and possibly compromising the whole system.
        On that subject, I’ll always remember this article by Aleph One:
        This is very old stuff (1996!) but nothing has changed, really…

    2. Lasana Murray wrote on

      The Web started with the concepts of interlinked documents and being able to reference information easily. It’s not far-fetched that a Web browser would want to support different open document formats. It just might not be all that practical given the complexity and potential for bugs involved.

      I think it’s time browsers separate into application browsers, document browsers and content browsers. The way things are now, users are like pigs lined up in a slaughterhouse. Unaware of what is going on behind the scenes or what is to come.

  8. Larry Jones wrote on

    I’ll update (if the window 10 allows me to. It’s been a bit of a dictatorship around here.)

  9. Matthew wrote on

    I’m confused. I’m running Firefox on Mac OS X. Firefox -> About Firefox says: “Firefox, 39.0, Updates available at

    When I click on the above link, I am taken to this page:
    The page says: “Congrats! You’re using the latest version of Firefox”

    When I go to Preferences -> Advanced -> Update -> Show Update History, it says “No updates installed yet.”

    Given that I installed Firefox 39.0 several days ago, there is no way I installed a version that was released on Thursday.

    about:config extensions.lastAppVersion and about:config extensions.lastPlatformVersion are both “39.0”

    So… what version of Firefox am I actually running? If I am running “39.0” and not “39.0.3”, how do I update? Do I really need to download and install a fresh copy of Firefox? Does the Update functionality that is apparently built into Firefox on OS X do nothing? Is there no button I can press to cause Firefox to check for updates?

    Very confused.

    1. Daniel Veditz wrote on

      If the dialog says that updates are available at our site rather than “up to date” or a button to apply a pending update then for some reason it can’t update you. Possibly you’re running under a user account that doesn’t have permission to write into the Firefox install folder? You could try simply restarting Firefox to see if that clears up its confusion. If that doesn’t work you can go to to get a fresh copy.

  10. AC wrote on

    Just today we had 2 users unknowingly sending gigs worth of egress traffic to AOL, Facebook and a bunch of other random IPs over port 80. One is a developer, the other isn’t. Both visited Israeli news sites. Neither use FireFox either (mainly IE and Chrome). Coincidence?

    1. Daniel Veditz wrote on

      Yes, coincidence.

      This attack was very specifically a Firefox attack, and the data was uploaded to a private server not to AOL or Facebook. There are lots of other attacks out there.

  11. Fiberglass chopped strand mat wrote on

    Could you provide shell script that would list files accessed by this exploit ? When you say for example “text files” do you mean “*.txt” or mimetype text ? If keepass file has “pass” in name would it be stolen ?

  12. Neil wrote on

    My Firefox ESR says it’s up to date (31.8.0). Should it be updating me to 38?

    1. Joe wrote on

      The only version affected is 38.x. If your ESR is earlier you have nothing to worry about. [source](

      1. libpython3-dbg wrote on

        I’m wonder where does that information come from.

        PdfJs.jsm, the file where the bug seems to have been found (see how it was fixed [0]), was not changed between versions 37 and 38, so at least the version 37 should be vulnerable too.


        P. S. Pretty symptomatically that we both have to refer to Debian for details. It looks like Mozilla decided to act like a non-free software developer: ‘Sorry, we have fucked up, but we do not say you where and how exactly, you just have to install our latest update’.

  13. Ricky wrote on

    Is there anyway of blocking this without updating the whole firefox itself, like remove the pdf reading component?

    1. Dmitry wrote on

      Is it possible to remove that PDF component?

      1. Ricky wrote on

        Don’t know…at least I was not able to locate the “pdfjs” file.

    2. RGoatse wrote on

      Yes, about:config, pdfjs disabled true

      1. Daniel Veditz wrote on

        Or on the Applications tab of the preferences window scroll down to PDF and change “Preview in Firefox” to one of the other options.

        1. Ricky wrote on

          Thank you.

  14. John Gordon wrote on

    I assume using NoScript set to block all javascript unless I click “temporarily allow all” would prevent this flaw. It’s amazing how many sites, including this one right now, work fine without javascript enabled (even Stack Exchange though a warning appears that the site works best with javascript enabled).

    1. O wrote on

      As of now, it looks like you’re fine only if NoScript does not allow pdf.js. I would also like to know whether it was required to enable scripts on that site to be exposed at all, or it was just enough to have pdf.js on whitelist. Will we be provided with any more details at all?!

      1. O wrote on

        Yeah, why aren’t we provided with more details?! I use NoScript, but pdf.js was whitelisted. :/ Does it mean I’m screwed, or it doesn’t?!

        1. O wrote on

          Sorry, I’m so f*^$(#% angry I didn’t notice I reply to myself. x-(

        2. Daniel Veditz wrote on

          You should be fine if you have NoScript because that will prevent the attack script from manipulating the PDF Viewer.

          1. O wrote on

            Thank you for your reply, Daniel. And sorry for being rude. It’s a bad feeling to possibly be a victim of such exploit.

            To sum it up: my NoScript did not block pdf.js istelf – it was on a whitelist. Nevertheless, the malicious website still had first to run some other JS code just to trigger pdf.js and only after that the exploit could be run? So having NoScript enabled in such situation would still save me from being attacked, even though pdf.js itself wasn’t blacklisted?

            Are you going to publish any details of this exploit and how and were did it work precisely?

  15. redwolfe_98 wrote on

    if “pdfjs.disabled” is set to “true”, in FF’s “about:config”, does that mitigate the vulnerability? i am just curious..

    1. Ricky wrote on

      That’s also what I’ve been done right now.

  16. Peter wrote on

    Are the details of the bug public yet?
    I’m just curious what kind of bug this was, can you share anything on this? Was it in Javascript or C++ code? A logic problem? Unintended consequences of design? Buffer overflow? Some kind of script injection? Caused by what? A silly typ? Like “Gotofail”? Or “AppleSSLBug”? …

  17. Nick wrote on

    Can somebody explain this vulnerability & solution in Plain English? I’m a FF user but not a techie and these comments have caused concern W/o my being able to fully understand//Resolve…

    1. redwolfe_98 wrote on

      all you have to do is install the updated version of “firefox”..

  18. Qu wrote on

    What older versions of FF are affected?

  19. A.Lepe wrote on

    I would like to know through which ads network this code was deployed (to see if the websites I visit are under that specific network). Also which ff plugins effectively blocked those ads?. It says it was found in a news site in Russia, but are there any reports of any other non-russian sites? I’m worried because this means that the code was able to access my encrypted directory as the browser is ran by the same user (something I will need to change from now on). How come the local files can be accessed with JS?, I thought that was well protected. Anyway, I think more details would be helpful to know if we could have been affected or not.

  20. Lrrr wrote on

    Hey, stupid mozilla’s team,

    How long you going to be silent about details of this epic bug? You should provide at least affected versions by this vulnerability and scenario of its triggering in some public press release.

    Or maybe you belive every potential user of your browser codebase should reissue all its authentication data every day of its usage just because some idiot decide to embed the crappiest PDF viewer in the world?

More comments: 1 2 3 4 5