Vulnerability Information Wants to Be Free

 
 
By Larry Seltzer  |  Posted 2009-02-25 Email Print this article Print
 
 
 
 
 
 
 

Companies that hide vulnerability information and take months for critical patches don't serve their users well.

Some software companies have learned a lesson from this decade that you don't protect your customers by pretending that vulnerabilities don't exist in your software. And then there's Adobe.

The story of the latest zero-day exploit of a vulnerability in their products tells a sadly familiar tale of how low a priority vulnerabilities are to the company, and how their instinct is to hide information. Even though exploits have been in the wild since at least January and probably December, the company is promising a fix on March 11. Today it finally revealed that patches for versions 7 and 8 will be released a week later, March 18.

But what's really galling is the absence of any information provided by Adobe on the vulnerability until today. That information, in a post on the Adobe Product Security Incident Response Team (PSIRT) blog, is mostly a bunch of links to anti-malware products from third parties and a few advisories from outsiders on the issue, not details from Adobe.

In fact, the only details on the vulnerability that have come out are from the Sourcefire Research Team, which followed up with Snort rules for the exploit and even a homebrewed patch. The patch is interesting, in that it's just a hacked-up AcroRd32.dll from Acrobat Reader 9.0, meaning that they are redistributing an Adobe file. I can't believe they have Adobe's permission for this; the real AcroRd32.dll is digitally signed, so the signature in the Sourcefire-hacked version fails. And yet after 2 1/2 days the homebrew patch is still up there. Could it be Adobe doesn't want to be so inconsiderate to their users as to stop the only protection they can get? And Sourcefire isn't even promising that this patch is definitive for the issue, just for the technique they described in their other blog entry.

This new vulnerability is a very big deal. We now know that it affects Acrobat and Reader versions 7 through 9. We know that it affects Acrobat and Reader on Windows, Linux and Mac OS X. As a practical matter, exploits would likely be specific to one OS and therefore it will be Windows, but a targeted attack against OS X or Linux users is perfectly plausible. Just use the handy proofs of concept available to anyone.

I came late to the full disclosure camp, and I'm not as far into it as some. I don't see, for example, a reason to disclose details of vulnerabilities if there is no public disclosure of them and no evidence that they are being exploited in the wild. But once there is evidence that there are exploits in the wild a company has a duty to provide its customers with information on the vulnerability, how to mitigate it and how to assess if they are vulnerable. This last point means that proofs of concept are a valuable defensive tool.

The famous HD Moore explains it in his Metasploit.com blog: The Best Defense is Information. At a time when it knew the vulnerability was being exploited in the wild and must have had samples, Adobe sat on the information. They only disclosed anything after the Shadowserver people forced its hand. Adobe customers, if they have brains, will find and use the outsider tools such as the Sourcefire stuff, but Adobe should be providing this information. Moore even draws a clear distinction between the behavior of Adobe and Microsoft; the latter has found religion when it comes to quick reaction to known exploits.

The people who write the malware have access to this information if they want. It's only the honest people who are harmed when companies fail to disclose. 

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.

 
 
 
 
 
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...

 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel