Exploits of Adobe's PDF explode, will continue to climb in 2010

Microsoft says 46 percent of browser exploits were aimed at Adobe's Reader PDF, and researcher says sandboxing the free viewer may be the answer

Exploits of Adobe's PDF format jumped dramatically last year, and continue to climb during 2010, a McAfee security researcher said Wednesday.

Microsoft, meanwhile, recently said that more than 46 percent of the browser-based exploits during the second half of 2009 were aimed at vulnerabilities in Adobe's free Reader PDF viewer.

[ Check out the Q&A with the CTO of eEye Digital Security, discussing the growing criticism of Adobe. | Master your security with InfoWorld's interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]

According to Toralv Dirro, a security strategist with McAfee Labs, the percentage of exploitative malware targeting PDF vulnerabilities has skyrocketed. In 2007 and 2008, only 2 percent of all malware that included a vulnerability exploit leveraged an Adobe Reader or Acrobat bug. The number jumped to 17 percent in 2009, and to 28 percent during the first quarter of 2010.

"In the last three years, attackers have found PDF vulnerabilities more and more useful, for a couple of reasons," Dirro said. "First of all, it's increasingly difficult for them to find new vulnerabilities with the operating system and within browsers that they can exploit across the different versions of Windows. And second, Reader is one of the most widely deployed applications that allows files to be accessed or opened within the browser."

Other factors for the jump in PDF exploits, argued Dirro, range from user belief that PDFs are safe to open, or at least safer to open than Microsoft Office documents, to the age of Adobe's code. "Quite a lot of PDF code was written years ago, and attackers are finding new security problems that no one thought of then," Dirro said. "That makes it difficult for Adobe to clean it up."

A recent discovery illustrated Dirro's point. Earlier this month, Belgium researcher Didier Stevens demonstrated how malicious PDFs could use a by-designed feature of the PDF specification to run attack code hidden in the file, and how to modify a warning message that Adobe Reader displays to further trick users into opening the document. Although some of what Stevens revealed has been publicly known for at least eight months, the technique has only been picked up by hackers in the last several weeks.

A major malware campaign using Stevens' tactics began Tuesday, with malicious PDFs attached to messages masquerading as instructions from companies' network administrators.

Microsoft also recently reported that PDF exploits remains a potent part of hackers' arsenals. In its newest Security Intelligence Report, Microsoft said that nearly half of all browser-based exploits in the second half of 2009 targeted Adobe's Reader. Three Reader vulnerabilities -- which were patched in May 2008, November 2008 and March 2009 -- accounted for more than 46 percent of all browser attacks.

McAfee rival Symantec has also tracked an explosion in PDF-based attacks. According to Symantec's latest Internet Security Threat Report, published last week, malicious PDFs were responsible for 49 percent of all Web-based attacks in all of 2009, compared to just 11 percent in 2008.

Like McAfee, Symantec also recorded a surge in reported Adobe Reader vulnerabilities. Of all browser plug-in bugs logged last year, 15 percent were in Reader's add-on for Internet Explorer, Firefox, Chrome and other Windows browsers. That was almost a four-fold increase from the 4 percent in 2008. And two of 2009's top five exploited vulnerabilities were in Adobe Reader.

Adobe declined to comment specifically about McAfee's and Microsoft's statistics on Reader vulnerabilities. Instead, a spokeswoman forwarded a statement the company has used before. "Given the relative ubiquity and cross-platform reach of many of our products, in particular our clients, Adobe has attracted -- and will likely continue to attract -- increasing attention from attackers," she said in an e-mail. "The majority of attacks we are seeing are exploiting software installations that are not up-to-date on the latest security updates."

The company's latest security move attempts to address the update issue; on April 13, Adobe switched on a service that silently updates customers' copies of Reader and Acrobat.

Adobe may be working on other ways to beef up Reader and Acrobat. According to one security researcher, Adobe will add sandboxing defenses to its PDF software this year. Sandboxing, perhaps best known as a technique used by Google's Chrome browser, isolates processes from each other and the rest of the machine, preventing or hindering malicious code from escaping an application to wreak havoc or infect the computer with malware.

Adobe has acknowledged it will add sandboxing to Flash -- another of its products that is frequently targeted by exploits -- and has it at the top of its to-do list, according to Paul Betlem, senior director of Flash Player engineering.

Reader may, or may not, get sandboxing as well. When asked about the reports that Reader 10 would include sandboxing defenses, a company spokeswoman said Adobe had no announced plans but was "investigating how to get different features to work in a sandbox."

McAfee's Dirro said adding sandboxing to Adobe Reader would be a smart move. "It's one of the most useful ways to address a lot of different vulnerabilities," he said. "Sandboxing had proven to be fairly efficient at stopping attacks."

Gregg Keizer covers Microsoft, security issues, Apple, Web browsers and general technology breaking news for Computerworld. Follow Gregg on Twitter at @gkeizer or subscribe to Gregg's RSS feed. His email address is gkeizer@ix.netcom.com.

Read more about security in Computerworld's Security Knowledge Center.

This story, "Exploits of Adobe's PDF explode, will continue to climb in 2010" was originally published by Computerworld.

Copyright © 2010 IDG Communications, Inc.

How to choose a low-code development platform