No JavaScript Needed For New Adobe Exploits
bl8n8r writes "More woes for Adobe as a security firm creates a proof-of-concept attack that injects malicious code as part of the update process. The user only needs to click a dialog box to execute the code and no JavaScript is needed to launch the exploit. The exploit affects Foxit as well as Adobe Acrobat software. This exploit is made possible through the host software allowing execution of system binaries. Not clear if it's multi-platform, but seems plausible."
Since it's part of the PDF specs, it should work in Linux too. What's even worse than with Windows is that since 'rm' is just a normal binary the PDF can launch that, and if you run as root privileges, just issue a command like "rm -rf /". If you don't run as root, then for example Ubuntu should give you the sudo box to input password to. This of course being just one of the examples it could do. Remember that most malware doesn't even need root access to function.
Another reason why it would be even more serious on Linux is the way you can pipe commands and how most systems come pre-packaged with a ton of little utility apps. You can create the whole malware with a series of commands, or wget a bash script from the internet and start that to hide even more malware in the system. Since most Linux systems dont even have the kind of application firewalls or antiviruses that Windows does, and because the Internet accessing is actually done via wget, they don't even get any kind of a "Give internet access to this application?" dialog.
It also doesn't help at all that most Linux users (especially those who are told so by the geeks!) believe that Linux cannot get malware. In my opinion this is a really stupid thing to do from those promoting Linux or Mac OS X as it will just lead to false sense of security.
Have the dialogue control specify that you are potentially allowing the PDF to alter other documents (maliciously or otherwise).
It's not exactly the first time a method of using social engineering to trick people has been part of a standard. Altering the status bar in JavaScript in order to aid phishing attacks was one.
I believe this exploit has already been patched in FoxIT, assuming this is the same exploit descibed here on SlashDot 2 weeks ago. Strangely, I haven't seen an update from Adobe ...
You clearly didn't read the article or even the summary. This exploit affects Foxit too. It's an exploit of the PDF standard itself
Screw adobe and other client side PDF readers. Am I vulnerable if I use Google's PDF viewer to view PDFs?t
Linux is a lot different than running as root all the time on Windows. My security updates are pushed to me as they are fixed, not even pushing up to a month of vulnerability to patch unlike some systems meant to make corporate IT admins happy. All popular Linux distributions have an updating function: you get your security patches and patches to everything else in your repositories a lot more consistently than Windows. To deny this shows unfamiliarity with Linux. Thats even before you get into functions like selinux and apparmor which happen to be standard on my flavor. For everyone. This is also an Adobe bug, and doesn't affect most Linux PDF readers as far as I'm aware and even if it did I'd have a lot more faith that the Linux ones would be rendered immune more globally than the hodgepodge of updating (or lack of) systems on Windows. You're pointing the finger at Linux and saying: "You're vulnerable too!" But in the practical real world it is a case of not.
Shh.
Most malware doesn't need root/admin access. It's only needed if you want to pwn or hack the server. Malware on the other hand runs just happily in userland too.
Dupe from Slashdot, March 31st
Because some genius thought that it was a great idea to put a launch command in the PDF spec.
Seems like it's working as intended.
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
Because some genius thought that it was a great idea to put a launch command in the PDF spec.
Yes. That should formally be removed from the ISO standard.
I tried the proof of concept code in SumatraPDF, and it didn't work. But may be a bug in SumatraPDF; there's an error message about a sync file failure.
As it’s apparently a standard PDF feature, giving it a shot to run whatever command line its author desires...
Yeah, it would affect anything that supported that feature.
Note that the clean pdf, after it is infected, pops up the window asking to run “firefox.exe sudosecure.net”. I’m not sure exactly how he did it, but note that there is a huge mass of text (judging from the scrollbar) above the “it’s okay, let me do this” message in the evil pdf. He’d have to somehow create a malicious binary and then execute it. One suspicion I have... a polyglot.
evil.txt:
Then...
Result: evil.pdf opens just fine in Acrobat Reader, but it has the injected code at the beginning, disguised as a comment.
No comment of whether it is specific to 32-bit or 64-bit versions of Windows... and why might that be significant, you ask? Because 64-bit versions of windows do not include DEBUG.EXE.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
Would switching to a non-Adobe PDF viewer make you safer? I understand this exploit affects Foxit, but there are many other exploits and PDF viewers (MacOS X's Preview, Ghostview/GSView, CutePDF, Nitro, etc.).
Usually the headline says the exploits are in Acrobat; and given Adobe's much larger installed base, they are a much more likely target; but perhaps the exploits are really in PDFs (or JavaScript) in general.
This feature is in the PDF specification, and in fact in the youtube video you'll notice that the trust manager warning is pretty severe "only do this if you trust the PDF" sort of thing.
To me its akin to downloading an EXE from a website with a browser and clicking the open button...
You clearly didn't read the last week's Slashdot article. This exploit is already fixed in Foxit.