How Not to Engender Confidence in Your Customers

By Larry Seltzer  |  Posted 2007-12-10 Print this article Print

Opinion: When someone reports a vulnerability in a product you're using, do you want the vendor to wake up the programmers or the lawyers?

I can imagine, back in 2000, a company taking offense at a vulnerability report and having a bad attitude about it. Back then you could forgive people for thinking that exposing such problems will make things worse. Things are different now.

There's only one way to approach such things these days: embrace the idea that strangers are going to be looking for vulnerabilities in your products. Tell them, and your customers, that all software products have vulnerabilities, but you're going to work promptly to fix yours.

Autonomy, makers of KeyView software, which performs file format interpretation among other things, took the wrong attitude. The company replied to a notice from Secunia about an upcoming vulnerability report with a threatening letter from their Associate General Counsel.

Secunia explains the whole situation, from their point of view, in this blog and link to copies of all the correspondence between the companies. It's just astonishing, if you ask me, that Autonomy would threaten legal action even if they think the report is false, and Secunia makes a good case that it is accurate. It's a complete loser of an approach.

KeyView, mind you, is exactly the sort of software that one would expect to have vulnerabilities that could be attacked with user input. It reads in and interprets a multitude of file formats, many of them quite old. File parsing code is prone to these problems; it needs heavy scrutiny and periodic reviews. The code in many of those interpreters is bound to be old and written in an era when these problems were not appreciated sufficiently.

McAfee and Secunia are each offering new freeware aimed at protecting users. Click here to read more.

In the case of Secunia and KeyView, the problem is the Lotus 1-2-3 parser. IBM includes KeyView with Notes and fixed the vulnerability Secunia was reporting in their releases. But that didn't fix the problem in KeyView's versions of the code. Autonomy's view of this is that the problem was already fixed. Secunia sees it differently.

I've been involved in performance-testing of software for about 20 years and every now and then you run into vendors whose license agreements forbid the use of the software for performance testing, at least for publication of the results. I'm not sure if this is still the case, but database vendors have been especially infamous for such provisions.

In the testing biz we've always tried to run as close to the edge as possible on these provisions, and it's tempting to just dare the vendor to sue you (of course only the loser of the test would do so). It's in this fine tradition that companies like Autonomy forbid the release of vulnerability information on their products: "...our license agreements expressly prohibit the actions taken by you in connection with your publication...."

I'm not a lawyer, and maybe provisions like this are ultimately enforceable. Maybe Autonomy can force Secunia to redact or even remove vulnerability reports on their products.

Who is the more damaged party in this event? I know if I were a KeyView customer (or a customer of IBM or Symantec products which bundle KeyView) I could only conclude that Autonomy is more interested in hushing up vulnerabilities than correcting them. This is a sad state of affairs.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. Check out's Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at Security Center Editor Larry Seltzer's blog Cheap Hack More from Larry Seltzer
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