It’s not news that Adobe and their products are a major target of vulnerability research and malicious hackers. This is a trend that will only grow. If they were still doing such things, we could soon expect the Month of Adobe Bugs.
The major security story of a couple weeks ago was initially reported as a zero day, although it turned out that it was effectively patched by the current version. Still, Flash is very widely deployed and is therefore one of the top targets of malicious programmers.
If you believe Adobe’s numbers, Flash users update fairly aggressively, especially in the developed world. Perhaps it’s still not aggressively enough, as attackers are hot on Adobe’s tail.
We learned of a few examples recently from F-Secure. One fairly pedestrian exploit downloads and executes a Trojan Horse program. It’s interesting because it uses obfuscation of the shell code, although very simple obfuscation. A more thorough job might have been more difficult to detect.
Of course, Acrobat is also widely-deployed and heavily relied on by large corporations, lawyers, governments, etc., and it is also a major vehicle for real-world attacks, not just empty vulnerability reports. F-Secure reported about a week ago on a malicious PDF they received from VirusTotal. This one is a hoot.
The PDF uses a known vulnerability in Acrobat (they don’t say whether the vulnerability is patched, but I suspect not since it triggered on their test system). It drops two files in the .temp folder, an .exe and a second PDF. It runs the .exe and launches the PDF, which appears to be a Department of Homeland Security Form G-235A. The form is a red herring to distract you from the fact that the .exe is a rootkit and reports back through port 80 to malicious servers in China.
How do they make these malicious PDF files? F-Secure stumbled on that as well. The attackers use a tool like GenMDB. You give the tool the PDF you want to trojanize, the .exe you want to embed in it, and the platform on which you want it to run. GenMDB is an odd name; it must have been adapted from a tool to trojanize MDB (Microsoft Access) files, and this version should be GenPDF.
One Monster Attack Surface
Now Adobe is completing the circle by bundling Flash into Acrobat. This will create one monster attack surface. I’m not sure if it makes the problem worse or not to have it all in one program. One would hope they would keep unbundled versions of Acrobat and Reader on the one hand and the Flash Player on the other. But I suspect that’s not what they’re planning. As I heard it put once in a different context: You’ll have to take the whole gorilla-even if you only wanted the banana.
At least there are a lot of competitors in the PDF space, but it’s hard to see this as not leading to more attacks and more exploits and more compromised PCs through the Acrobat and Flash vectors. Adobe clearly tries, as one can tell from this overview of their security practices or this extensive paper on security in the Flash Player.
Acrobat opts into DEP (Data Execution Prevention) support on XP and Vista, and Adobe claims that Flash does (I know back in March it didn’t, so perhaps this is brand new). But neither opts into ASLR (Address Space Layout Randomization) on Vista. (It’s possible to force Flash to support ASLR). The new Acrobat Reader 9, available in July, will take advantage of both DEP and ASLR according to Adobe, as will Adobe Flash Player 10, now available as beta on Adobe Labs and expected to be generally available later this year, according to a company spokesperson.
These defense-in-depth measures can reasonably be expected to make practical compromise of clients far more difficult. Perhaps then, the real challenge to the company, as with Microsoft, is to get users off of old, defenseless versions and onto the new ones. This is, doubtless, the plan anyway.
I asked Adobe about these issues and got this response from Erick Lee, manager of secure software engineering: “Adobe takes the security of our products seriously, mindful of their wide use. We have a team dedicated solely to making sure our products are designed, engineered, and validated using security best practices. The Adobe Secure Software Engineering team, which I manage, has industry-leading experience in building secure applications and is a core service provided to all Adobe product teams, independent of any specific business or product line. Our secure software engineering practices include threat modeling, automated code audits, in-house fuzzing, bringing in third parties for external security reviews and more. “
As vendor quotes go, that’s pretty encouraging. Here’s to success in their efforts because insecure Adobe products are now officially bad for everyone.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer’s blog Cheap Hack.