Mozilla Security Blog
Categories: Firefox Security Security Updates

Firefox exploit found in the wild

Daniel Veditz

224 responses

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

              @leo
              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

    Hi!
    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

    Hello.
    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. https://news.ycombinator.com/item?id=10021376. 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:
        http://news.ycombinator.com/item?id=10021865

  16. alp wrote on

    Can you point to commits fixing this issue? Is it https://github.com/mozilla/pdf.js/commit/4f3f983a214867011dda8c5597a4d3523c5f1423 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.

  21. Bill wrote on

    Is it possible to get security updates WITHOUT the “user interface and feature enhancements”? I hate the way Mozilla shoves new looks and “we think you’ll love it” UI changes down our throats. Burnt in the past by that, I now don’t allow auto-updating. I’ve been on Firefox 33 for awhile now.

    Why can’t there be a separate security update, like Windows does? I don’t want whatever latest thing the Mozilla designer dreams up. But I want the security updates obviously.

    1. Robert O’Callahan wrote on

      Because after N regular updates and M security updates we’d be supporting O(N x M) different Firefox versions, which couldn’t possibly scale.

    2. Eamon Nerbonne wrote on

      You do realize, that (A) microsoft has far fewer updates to support, and (B) that even microsoft is turning away from that approach with windows 10. Alternatively, you could pick the android approach: lalalala what-do-you-mean, security updates? There’s no third option.

      At the end of the day, while I think it’s terribly annoying: users need to quit whining. Yes, it’s a pain in the ass – but the real issue is that people hate *any* change because we would all rather just stick to what works now. But that’s just not an option – the world’s changing all the time, and large (software) projects either need to adapt, or die. Without any exception all major software projects have this kind of functionality regressions in the name of being able to due new and different things.

      So the reality is that even if you’ve figured out *just* the right way for your computing environment to work, little will be left in 10-15 years because although change is painful, inflexibility is a lot more painful.

      If I were a betting man, I’d bet that Firefox is erring rather too much on the side of keeping growling (legacy) users at bay by avoiding changing, which will inevitably lead to obsolescence. All other browsers seem to have changed a rather lot more in the past decade.

    3. Eamon Nerbonne wrote on

      You do realize, that (A) microsoft has far fewer updates to support, and (B) that even microsoft is turning away from that approach with windows 10. Alternatively, you could pick the android approach: lalalala what-do-you-mean, security updates? There’s no third option.

      At the end of the day, while I think it’s terribly annoying: users need to quit whining. Yes, it’s a pain in the rear end – but the real issue is that people hate *any* change because we would all rather just stick to what works now. But that’s just not an option – the world’s changing all the time, and large (software) projects either need to adapt, or die. Without any exception all major software projects have this kind of functionality regressions in the name of being able to due new and different things.

      So the reality is that even if you’ve figured out *just* the right way for your computing environment to work, little will be left in 10-15 years because although change is painful, inflexibility is a lot more painful.

      If I were a betting man, I’d bet that Firefox is erring rather too much on the side of keeping growling (legacy) users at bay by avoiding changing, which will inevitably lead to obsolescence. All other browsers seem to have changed a rather lot more in the past decade.

  22. nope wrote on

    fucking clowns.

  23. Sloan wrote on

    Hmm. But how pdf.js even can (?) access local files?
    As I know local access from JavaScript browser API is restricted, no matter is AJAX or not. The only way – is using fileReader, but in this case you need manually load file from tag.
    So, how this possible?

    1. JJ wrote on

      Hackers gonna hack… Do you understand what “browser vulnerabilities” are, i.e., how they are discovered and, most importantly, for WHAT?

    2. Awal wrote on

      Very interested in knowing the same. I guess PDF.js is part of chrome code which has elevated privileges.

    3. Sloan wrote on

      Sure. But this is NOT a part of brower, this is an addon (I’m about pdf.js). So, every addon can access every (!) data that user can. That is madness!

  24. Marko wrote on

    Hello.I have beta 40 0 9 do i need to go to 39.0.3?Thanks

  25. Bottom jej wrote on

    Good job, Mozilla! Congratulations on hitting all time low market share of 9%
    I wonder why people are jumping this sinking ship…

    1. Joe wrote on

      You think Apple cares about market share? If you build a good quality product for a certain demographic, people will use it. Firefox serves the demographic that cares about quality open source projects that respect people’s rights.

    2. JJ wrote on

      4chan users are retarded. ALL software has vulnerabilities… You should be grateful this one is being reported AND mozilla is doing something as fast as possible. Other companies simply don’t care about the users. Mozilla is right here, and the best software organization from the users point of view.

  26. Ronan Jouchet wrote on

    Were Firefox users on non-release channels (beta, aurora / Developer Edition, nightly) vulnerable?

    1. Lagfox wrote on

      Yes. It’s fixed only in Firefox 38.1.1esr, Firefox 39.0.3 and Nightly 42.0a1

      1. Ronan Jouchet wrote on

        You mention esr, release, nightly. So currently, aurora (41.0a2 (2015-08-07)) and beta were and are still vulnerable?

        1. Stephane wrote on

          I feel it’s somewhat sub-optimal that the Firefox Dev Edition did not get a patch right away. What is the rational behind this? Are there not enough people using it? Thank you for the great browser 🙂

      2. Alica wrote on

        And what about the previous ESR 31.x? Will there be a ESR 31.8.1, like the ESR 24.8.1?

  27. paul wrote on

    Any idea how long this vulnerability has been in the pdf viewer? Are there known addresses that have been receiving the exploit uploads? That would allow inspecting firewall logs to see if any data has been exfiltrated.

    I’d be happier if Firefox did not have any access to the local file store other than a limited area for its own stuff, i.e. it ran in something like a chroot jail or under a separate user account. Not sure what it would have to do about FF’s own password store and the bookmarks db. Should everyone consider their password store to be compromised and change all the web passwords they have stored in it?

    I also see the root problem here as too much trust in JS sandboxing. An endless parade of exploits and privacy leaks have resulted from this. The decision a couple years ago to remove “turn off JS” from the UI has worsened this immeasurably, as well as cementing the bloaty, script-heavy, dysfunctional style of web design that everything is afflicted with now, that almost always has no user benefits over Web 1.0 style pages. The change should have gone the other way: JS should have been turned off by default, with whitelisting for specific pages. In any case the same-origin policy should be strengthened so that it is impossible for sites other than the one in the nav bar to run any scripts at all (that means no ads with scripts, no google analytics script, etc). That would stop a lot of user tracking among other things.

    1. Olegario Craig wrote on

      Yes, please; what were the IPs and/or domainnames used for the upload targets? I have flow logs going back a while…

  28. Thomas Quinot wrote on

    What’s the earliest vulnerable version? How to tell if the builtin PDF viewer is enabled?

  29. Vasim wrote on

    They are not only implementing a lot of potentially dangerous things into browser (pocket, pdf.js and other unneeded crap), reducing user’s ability to keep him/her safe (removed “turn off JS” from gui) but also trying to hide information about who could be affected from users! Why they’re hiding the “news site” and malicous ad reference? A lot of users can be affected, they should know about this.

  30. The Old Coot wrote on

    Shouldn’t be happening if you guys did better tasting on your code before releasing updates.

    1. James Edward Lewis II wrote on

      Read up on the halting problem: It implies that for sufficiently complex programs, testing will never be perfect.

      Mozilla actually does extensively test before pushing code out the door.

  31. Eye wrote on

    Why pdfjs is in there at all? Why pdf (actually paper printing format) is such popular over the internet?

  32. KX wrote on

    This exploit is more of a symptom than anything. It’s a symptom of how poor Javascript security really is.

    Javascript engines were originally implemented in a day and age where security wasn’t needed, JS was just used for moving stuff around the screeen, fluid motion of sites’ DOM elements, being able to drag stuff around, having client-side input validation and such. Thing is, over time, JS has gained a lot of responsibility as a language but security hasn’t been there to keep up with it. It’s still very permissive as it originally was, allowing third parties to run unprecidented amounts of intrusive code on user machines.

    We’re in a world where we have things like WebRTC exploits via JS being used by malicious marketing companies to bypass privacy tools as to probe internal network environments, advertisement networks being used to push malware using javascript, publishers who feel it is their right to enumerate every bit of information about a user’s computer just by connecting to their site. Now we have “local” javascript being leveraged to compromise local files.

    It’s become ActiveX all over again. This time, every browser has it and it’s obligatory to participate on the Web.

    Gone are the days where a computer firewall is adequate. In most cases, a browser punches a hole clean through conventional firewalls. Thus it is my contention that Mozilla and other browser vendors need to ramp up the security controls on Javascript bigtime. This includes controlling the entry and exit points into the engine and allowing users to control those points through non-hidden means (That means, not tucked away in about:config). The publishing industry may hate it but users at the end of the day need to protect themselves from malicious activity and the defaults on browsers simply doesn’t do it.

    We need to address this at the base of the situation and stop being so permissive with JS.

  33. Scott Walters wrote on

    Accessing an arbitrary file outside of $HOME/.mozilla/firefox seems like it should reasonably require approval via a confirmation dialog box each and every time.

    Similarly, right now, pop-ups are either on or off for a site, but the file upload dialog is considered a pop-up. This means that for sites like imgur.com, I have to turn it off to not be abused by ads pop-ing up windows to other sites, but have to turn it back on to be able to upload files. This is unworkable and far more work than simply approving each and every pop-up. Since I almost never want a pop-up and it’s easy to ignore the requests, this should be the default.

    I know software written in C is always going to have exploits, but it seems like Firefox has systematically struggled with a gap in understanding what’s permissible to do without approval.

    Considering that almost no one ever wants any site to ever be able to open a pop-up, and that Firefox continues to struggle with forbidding this after a decade, Firefox fails to inspire confidence. If Firefox is similarly reckless about accessing files outside of $HOME/~.mozilla/firefox without permission, then the only reasonable thing for people (and Linux distros, and ad-on security products) to do is to jail Firefox so that it can’t hurt itself.

    I already run Firefox as a non-privileged user with the install itself owned by root (and until settings were changed, Firefox was freaking out that it couldn’t write its own files to upgrade itself — damn right you can’t write to your own install!) but I doubt I’m careful enough with file permissions for even this to be adequate, and most users aren’t nearly this careful.

    Please keep in mind that it’s not just developers who need some level of security, for the sake of their projects, as this exploit shows. As Mitnick’s social engineering attacks show, even low level office workers need a reasonable expectation of security.

    tl;dr: You can try to write this off as a predictable, excusable security failure, but I see it as a long pattern of recklessness and disconnect from what’s reasonable that is inexcusable and puts Firefox in a bad light. Just as people shouldn’t need 3rd party pop-up blockers, dishing out files without explicit permission simply makes no sense. People almost never want that and if they do, they’ll approve the actual read or the actual pop-up.

    1. Anonymous wrote on

      That is actually a solution, force everything in mozilla firefox to be done in specified working directories including a specified temp & cache directory, unless permission is granted to do otherwise. A permission based system can be overlayed on that, saying that only a particular thread/process is allowed to access each folder.

      Move everything firefox needs to one place and lock it down.

  34. jmp wrote on

    I will end up running browsers from docker or some other container.

  35. Sayonji Nakayama wrote on

    Hi.

    Am I safe if my firefox doesn’t save passwords?

  36. Program indir wrote on

    Thank you…

  37. Chris Hills wrote on

    Can these types of vulnerabilities be mitigated with selinux or AppArmor?

    1. Roman Gorshunov wrote on

      Yes, with SELinux sandbox for example: http://danwalsh.livejournal.com/31146.html

    2. Erik wrote on

      A custom AppArmor profile could block Firefox from accessing .ssh, .purple, etc. I’m going to write one this weekend. It’s a blunt tool but better than nothing.

      1. Rick wrote on

        Ubuntu already has an apparmor profile that’s not on by default (/etc/apparmor.d/disable/usr.bin.firefox).

  38. someone wrote on

    a chilling reminder that the more “features” you keep incorporating to a browser, the more attack surface you will create… Mozilla, please come to your senses and stop the Firefox bloatware.

  39. Martin wrote on

    Thanks Mozilla, for adding a useless feature to your browser, making your bloaty code even more insecure. 🙁

  40. Neal wrote on

    Firefox really needs some hardening. I remember when the Firefox PDF viewer was introduced one of the benefits was supposed to be security. I am disappointed that all that seems have done is add a new exploit vector.

    I hope e10 brings some tangible security benefits. Unfortunately the sandbox doesn’t even have a estimated ETA, so we Firefox users we have to grow increasingly paranoid about our security or switch to another browser that doesn’t get publicly hacked so easily.

  41. Yellowberry wrote on

    Here is my take on this. Mozilla will do what they want. If you are not satisfied with this, then just fork Firefox and add and remove the features that you want. I know you might be saying “That’s too difficult and that takes work.” Well, I’m here to tell you that that is what it will take. I am disappointed that this is how it has to be. It seems a lot of software companies these days are steering away from the community…

  42. David wrote on

    Wow, I’m amazed that not one of the 90 previous comments mentions NoScript. Hello!!! If you want reasonably safe browsing you _must_ disable JavaScript for all untrusted sites (i.e. any site where you don’t recognized the URL, and probably many where you do).

    This issue is a yawn for anyone running NoScript. The mal-advertisement site JS would not have run at any time, past present or future. All such malware loads from garbage throw-away domains which could not possibly have appeared in the NoScript white-list.

  43. sametbh wrote on

    What if i rarely use PDF viewer and ghostery?

  44. Chris wrote on

    Does anyone know the IP/hostname of the server the data was sent to?

    1. Travis wrote on

      +1

      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 http://acintcdn.net/delivery.php which currently resolves to 185.86.77.48 (it can use either both POST and GET, so check for both)

  45. David Coston wrote on

    Thanks for the quick fix guys.

  46. Mark wrote on

    Mozilla is still one hundred and fifty thousand times better and safer then Internet Explorer.

  47. John Smith wrote on

    Is ESR 31.8 vulnerable to this? If so, will there be a bugfix release? The ESR roadmap still shows it as being supported.

    1. Neal wrote on

      I think next week it is discontinued. You will have to update to ESR 38.

      Maybe the Mozilla people don’t want to do a last update for a version that only has less than a couple of days of official support.

  48. Livid wrote on

    PDF.js is introduced in Firefox 19

    Firefox 19 is released in early 2013

    Does that mean the exploit has been around for over two years?

    1. Blath wrote on

      Since Fx 31.x seems not to be vulnerable, no.

  49. AS wrote on

    The Firefox update has stopped my laptop connecting to the internet! Now even interest explore no longer works! What can I do?

  50. tasty wrote on

    who’s wanna analyze a lil’ some? rghost.net/6HTzsrdLR

    I guess we need to block requests to ‘acintcdn.net’ further.

    1. j wrote on

      File is deleted

      1. libpython3-dbg wrote on

        Here it is, I guess.

        http://paste.ubuntu.com/12030863/

        I’m actually quite disappointed by Mozilla’s attitude. It is in ‘best’ traditions of non-free software developers. What is that conspiracy for — I’ve found the exploit in a minute, but cannot find out which versions of Firefox are affected (since 19? since 31? since 38?) — the corespondent bug report [1] is classified (sic!). Are they suggesting me to try out by myself?

        [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1178058

    2. O wrote on

      Was this host already on Opendns’ Family Shield blacklist maybe?

    3. O wrote on

      Was this host already on OpenDNS’s Family Shield blacklist maybe?

  51. bob wrote on

    using different layer for different task = being secure
    like a VM, docker, sandbox for your daily navigation
    another VM, docker, sandbox for your daily work

    1. eliasp wrote on

      If you’re considering Docker to be a security feature, your security concept is broken.
      Docker is a lot, but _not_ a security layer/feature.

      1. Alex wrote on

        I don’t think he is implying the Docker is inherently the solution to security, in fact, he includes Docker with a list of other possible solutions. Layering up with a VM purely for browsing will protect you from this particular browser exploit, given that you use another VM for your development work.

        1. Joe wrote on

          Wasn’t there just a VMware escape published?

          1. Josh wrote on

            XEN escape*

            Yes

            1. Ben wrote on

              XEN and KVM escape caused by QEMU bug.

              And feel free to try which category of bug is easier to exploit, this one or so-called VM escape.

      2. Gerard Braad wrote on

        He means to uses Docker as a separation between two environments/contexts. Docker uses namespaces to create an isolation between these two contexts.

  52. Uil wrote on

    I wonder why they forbid reading this in lynx – do they fear people keeping their systems scure?
    BVut of course you can read it in lynx if you change the user agent string, which goes to show they are really fearing us.

    1. Daniel Veditz wrote on

      This is just a hosted instance of Word Press. If it’s blocking lynx you’d have to ask them — we have absolutely no interest in preventing people from accessing our blogs.

  53. Michal wrote on

    Hi,

    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 ?

    Thanks,
    Michal

    1. Daniel Veditz wrote on

      We’ve now seen variants looking for different files, though so far similar lists focused on developers / command-line users. In the article text files meant .txt. In the variant I saw if the keepass file name has a .txt extension it would be stolen.

  54. Jk wrote on

    Can you provide hashes of the samples?

  55. G. R wrote on

    Has Nightly also received this patch?

    1. Daniel Veditz wrote on

      Yes, all the branches have the patch.

      1. paul wrote on

        What about beta x64?

  56. Eugene wrote on

    Oh my, really? How it could be happen? Probably coz Firefox let third-party software to install their plugins without user permisson (Adobe Reader/Acrobat, NFW, etc.)? Or due to the absent option ‘ask user’ for some filetypes open dialog (RSS, podcats, etc)? Really, wery strange /irony off/

    1. James Edward Lewis II wrote on

      The problem was actually in Firefox’s built-in PDF reader, based on the old PDF.js project, so it has nothing to do with third-party plugins (even though they *do* pose a security risk generally).

      1. Eugene wrote on

        I’ve got it. My idea was: let the users decide what to open in browser themselves.

  57. mseri wrote on

    if you look for a desktop sandbox, you could consider qubes-os. It’s getting better and better

  58. tan wrote on

    Looks firefox is doing a job to keep up with the safety and security. Well done.

  59. shadowspear wrote on

    It looks like we have to get the people like firefox, opera, google chrome, and any other software used for surfing the inter net to stop all this bs with people being allowed to use java and or any other kind of program. having access to and or changing browser on peoples computers. and also stop them from taking data just to use for their sales, and or selling to third parties.

    It really is getting bad when any and or all the browser are now able to hijack your computer, and or let third parties have the abilities to do so when they should have always an option to lock them out and not take part and know exactly what is being installed on anyones computer.

    1. James Edward Lewis II wrote on

      This particular bug was in a component of Firefox itself, not in any third-party plugin.

    2. urmom wrote on

      Yeah I’ve said for a long time now that this whole infatuation with javascript and overcomplicated/bloated browsers is only going to cause more problems. It should be possible to use something simple like Dillo to browse the web. You want security and stability? Ditch the Web 2.0 crap. It’s not worth the security and privacy problems. Building stupid “countermeasures” on top of this shaky foundation is only going to lead to an arms race. Fix the fundamental problem, not the symptoms. KISS principle applies, as always…

      1. gary wrote on

        Yeah, let’s stop with this internet of things crap. All we need is a handful of nice single-player games and stop this insanity.

  60. William wrote on

    Thanks for patching the bug, but I’m starting to lean towards sandboxed web browsing as employed by Chrome.

    1. George8211 wrote on

      Perhaps you want to take a look at the e10s project? http://wiki.mozilla.org/Electrolysis

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

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

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

  64. 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).

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

  66. 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; http://www.sandboxie.com which got good reviews https://www.grc.com/sn/sn-172.htm

        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: https://danwalsh.livejournal.com/28545.html
      And firejail as mentioned is at: https://l3net.wordpress.com/projects/firejail/

  67. 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: http://insecure.org/stf/smashstack.html
        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.

  68. Larry Jones wrote on

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

  69. Matthew wrote on

    I’m confused. I’m running Firefox on Mac OS X. Firefox -> About Firefox says: “Firefox, 39.0, Updates available at https://www.mozilla.org/firefox/”

    When I click on the above link, I am taken to this page:
    https://www.mozilla.org/en-US/firefox/new/
    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 https://www.mozilla.org/en-US/firefox/all/ to get a fresh copy.

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

  71. 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 ?

  72. 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](https://security-tracker.debian.org/tracker/CVE-2015-4495)

      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.

        [0] https://anonscm.debian.org/cgit/pkg-mozilla/iceweasel.git/diff/?h=upstream/38.1.1esr&id2=upstream/38.1.0esr
        [1] https://anonscm.debian.org/cgit/pkg-mozilla/iceweasel.git/log/browser/extensions/pdfjs/content/PdfJs.jsm?h=upstream/38.1.1esr

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

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

  74. 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?

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

  76. 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”? …

  77. 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”..

  78. Qu wrote on

    What older versions of FF are affected?

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

  80. 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?

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

  82. Lars Schotte wrote on

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

  83. Kaptak wrote on

    Thank you

  84. 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…

    download-installer.cdn.mozilla.net 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.

  85. Mike wrote on

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

  86. 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 http://acintcdn.net/delivery.php which currently resolves to 185.86.77.48 (it can use either both POST and GET, so check for both)

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