eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
When I read about the serious vulnerabilities in the Kerberos v5 authentication system, one specific aspect of it caught my eye: The lesser of the two issues was related to the ASN.1 library, a library for managing data formats and interchange of data between systems.
ASN.1 is a very popular standard and set of libraries used by a vast number of products, both commercial and free. In early 2004, it landed in the news as the object of a series of serious vulnerabilities in Windows, and Check Point had a problem with its ASN.1 libraries later on.
The ASN.1 libraries are really fundamental stuff and need to be as secure as possible. I dont want to rush to the conclusion that the ASN.1 libraries used in these products are badly written, all things considered, but when code is widely used and especially when its used by kernel-level processes, it needs special scrutiny.
When a common library develops a hole, the list of affected products can be immense. Consider the recent PNG (portable network graphics) library bug, the one that affected a large collection of open-source products including Mozilla, ghostscript and perl-tk. These vulnerabilities worry me because the news doesnt necessarily go out that theres a bug in ghostscript, and yet ghostscript users need to upgrade.
OpenSSL is another popular program included in many other packages, including just about every Linux and BSD distribution, and it has had several security holes over the past year or two. This one, ironically, has to do with its interaction with ASN.1.
In recent years, weve also had a worm targeting OpenSSL and an HTTPS DOS (denial of service) issue in OpenSSL.
I spend a lot of time every day tracking security vulnerability reports, and I have a tough time keeping up with it all. Bugs such as these, in libraries, can create subtle problems that can go completely unnoticed unless the developer happens to be alert and conscientious enough to do something about it.
When a famous product is involved, such as OpenSSL in a Linux distro or libpng in Mozilla, the developers are going to be on top of things. But what about that custom application that a consultant wrote for you? The contract is over, and sure, it would be great if she remembered and let you know, but that would be lucky. I suspect that many silent attacks happen through holes such as these, where no obviously vulnerable products are in use.
There are solutions to problems like this, but they dont come cheaply or easily. Network vulnerability scanners from companies such as eEye can search for vulnerable products on your installation, or you could go it alone and keep track with a good information service such as Symantecs Deepsight Threat Management System.
But you at least should be aware that some vulnerability reports may apply to you even if you dont directly use a product of that name. Read the fine print and re-evaluate your systems.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page:
More from Larry Seltzer