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. I’m honestly not sure what happens if you select the built-in viewer from that prompt.
“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.
This version at least submits to which currently resolves to 185.86.77.48 (it can use either both POST and GET, so check for both)ĭid 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.
I’ve found one copy of the the exploit code that targets Windows, Linux and Mac (based on atform so other OSs should be fine). 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 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. What are the “eight different popular FTP clients” targeted on Windows? 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. An additional root certificate may need to be imported.
The server might not be sending the appropriate intermediate certificates. The certificate is not trusted because the issuer certificate is unknown. Back to IE…ĭ uses an invalid security certificate.
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. SELinux that bullshit and contain it to its own crap, done. 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? Browse free.Ģ24 comments on “Firefox exploit found in the wild”
People who use ad-blocking software may have been protected from this exploit depending on the software and specific filters being used.
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. The exploit leaves no trace it has been run on the local machine. Mac users are not targeted by this particular exploit but would not be immune should someone create a different payload. 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. 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. purple and Psi+ account information, and site configuration files from eight different popular FTP clients. On Windows the exploit looked for subversion, s3browser, and Filezilla configurations 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. This allowed it to search for and upload potentially sensitive local files. 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. Mozilla products that don’t contain the PDF Viewer, such as Firefox for Android, are not vulnerable. The vulnerability comes from the interaction of the mechanism that enforces JavaScript context separation (the “same origin policy”) and Firefox’s PDF Viewer. The fix has also been shipped in Firefox ESR 38.1.1. All Firefox users are urged to update to Firefox 39.0.3. This morning Mozilla released security updates that fix the vulnerability. 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.