Newfound flaw in compression utility could have widespread effects

While no new critical threats have surfaced this week, a number of "smaller" threats have emerged. Most important, a highly critical flaw in the zlib compression utility could have wide-reaching consequences. John McCormick has the details in this edition of the IT Locksmith.

Another slow week in the security world doesn't mean that the coast is clear. A newfound vulnerability in the zlib compression utility has the potential to wreak widespread havoc, and a cell phone Trojan could rat out employees for playing games on company time. In addition, two respected security companies lose a little credibility after an odd marketing choice.


Once again, while no big critical threats have surfaced this week, a number of "smaller" threats have emerged—and no threat is negligible if it affects your system. However, there is one new threat that stands out because it makes everything from cell phones to the Xbox vulnerable.

Secunia reports that a boundary error check routine in inftrees.c has resulted in a vulnerability in the zlib general-purpose, lossless compression utility. The threat is highly critical because it can not only trigger a denial of service event, but it can also permit an attacker to execute random code on the vulnerable system.

Gentoo's initial report on the CAN-2005-2096 vulnerability identifies all versions prior to 1.2.2-r1 as vulnerable. There is no known workaround, so you need to update the library to the latest version.

I'm giving this threat top billing because it affects everything that uses OpenSSH. So, while it may turn out to be a minor threat, it has the potential to be very widespread.

Developers use zlib in a vast number of operating environments, including BlackBerrys, BeOS, PDAs, and even now-obscure languages such as Pascal, as well as some Perl and Java code. Of course, the library also has uses in all the usual suspects, including Windows, Solaris, and Linux.

In addition, Mac OS X includes the zlib library; most other environments mentioned don't include zlib unless some developer has used the library. Some of these are ports of the library and may not contain the buffer overrun vulnerability—then again, they might, and it's always better to err on the side of caution.

Next, warn any users of Symbian mobile phones in your company not to download any games to their phones. A new Trojan (Doomboot.a) has surfaced in some games. Those who have already downloaded the Trojan are likely to have learned their lesson because the Trojan performs continuous nonsense actions that quickly drain the handset's battery, and it deletes everything stored on the phone.

A few weeks ago, I wouldn't have included this in a professional forum because I never thought anyone with a real job would have so much free time that he or she would need to play games on a cell phone. Then I received a call from a client asking why his salesman's phone had lost all of his stored contact information. Personally, I would have fired the guy because he obviously has too much time on his hands that he should probably be devoting to selling.

Finally, in the really dumb moves department, ZDNet Australia reports that Computer Associates and RSA, both obviously deeply involved in promoting computer security, have recently sent out e-mails with masked links embedded in the messages. That means when you click a link in the HTML e-mail message, it takes you to some unexpected URL.

If you haven't received your regular dose of promotional or even security messages from either vendor, it may be because secure e-mail filters recognize this as a common practice used by phishers who regularly tie common addresses such as to some completely different URL that they control. While the masked links are actually legitimate (and probably due to some marketing intern thinking it was a good idea), this has got to go on this year's list of the dumbest moves by any security company.

Although the accidental phishing mistake is bad, the companies will likely survive just fine. After all, it doesn't come close to Microsoft's similar blunder in 1995, which involved sending out a CD-ROM that contained the first example of a Word macro virus.

Final word

I hope all the fans of open source software take note that the zlib vulnerability has probably been around for a very long time because it's in an underlying component. Of course, the problem isn't limited to open source; I'm only mentioning that fact because of all the claims that open source is more secure due to the many different eyes that can find flaws. Open source is fine—I use it myself. However, I don't have blinders on about its superiority to commercial software.

If you don't see any potential danger in relying on freeware when developing commercial applications, check out this note about one of the authors completely abandoning the project. When something is free, the incentive to keep producing updates can easily disappear, pushed to the back burner by the near-universal need to make a living. The biggest problem with developing freeware is typically the mushrooming demands on a developer's time from people who simply won't read the documentation (a problem familiar to any help desk operator). And the more useful and popular the tool, the greater the demand on the author becomes.

My biggest security concerns always revolve around problems discovered in libraries or encryption algorithms, which can go undetected for years. These problems eventually turn up after developers have embedded them in thousands of applications, making them incredibly difficult to root out. How can we ever hope to have secure software when compilers are sticking 10- and 20-year-old code into new applications?

In the past, I've also reported on a longstanding flaw in some optimizing compilers that actually remove security features carefully inserted into code by good programmers. The optimizer code would delete lines of code if it couldn't determine that they served any purpose. Unfortunately, that means sometimes deleting a line used to zero out a password or a similar security step. The developer would never even know it was gone, leaving a password floating around in memory.

While people complain about sloppy programming, it's important to realize that even a careful programmer may be using a compiler, library, or algorithm that contains a fundamental flaw. And that's the root cause of many buffer overrun vulnerabilities (such as the one in sys-libs/zlib)—not sloppy programming.

Miss an issue?

Check out the IT Locksmith Archive, and catch up on the most recent editions of this newsletter.

Want to stay on top of the latest security updates? Automatically sign up for our free IT Locksmith newsletter, delivered each Tuesday!

John McCormick is a security consultant and well-known author in the field of IT, with more than 17,000 published articles. He has written the IT Locksmith column for TechRepublic for more than four years.

Editor's Picks