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. شركة مكافحة النمل الابيض بالرياض wrote on

    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?

  2. Lars Schotte wrote on

    SELinux that bullshit and contain it to its own crap, done.

  3. Kaptak wrote on

    Thank you

  4. Ted wrote on

    You’d think, for all the sensitivity of this, Mozilla would tighten up their shot group and make it easier for folks to download the update when using Firefox. Back to IE… uses an invalid security certificate.
    The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported.
    (Error code: sec_error_unknown_issuer)

    1. Daniel Veditz wrote on

      What browser are you using? Have you disabled any built in root certificates? Are you under a Man-in-the-Middle attack replacing the certificate? From here the site has a perfectly valid cert issued by DigiCert that should be accepted in all current browsers by default.

  5. Mike wrote on

    What are the “eight different popular FTP clients” targeted on Windows?

  6. Gav wrote on

    Is there any chance you could publish the server names or IP addresses where this data was uploaded to? It would be useful to be able to check quickly whether anybody at our site was hit. I can’t find anything in any of the write ups that document this (though given the publicity around this issue it’s like finding the proverbial needle), but it would be useful to at least be able to notify people here that were definitely affected

    1. Gav wrote on

      I’ve found one copy of the the exploit code that targets Windows, Linux and Mac (based on navigator.platform so other OSs should be fine). This version at least submits to which currently resolves to (it can use either both POST and GET, so check for both)

  7. Puppy wrote on

    Did Options: Application -> Content type PDF set to ‘Always ask’ mitigated the vulnerability or the internal PDF viwer JS code was abused regardless the setting ? Thanks.

    1. Daniel Veditz wrote on

      “Always Ask” would certainly mitigate the drive-by aspect, and you’d also be safe if you then chose to open PDFs in some other viewer. I’m honestly not sure what happens if you select the built-in viewer from that prompt. If it opens the PDF Viewer in a new tab that would be safe (and I suspect this is what it would do); if it opens the PDF Viewer in the original frame that may or may not be vulnerable. It should break the current exploit because of the asynchronicity, but whether that could be worked around or not would take some investigation.

More comments: 1 3 4 5