ZIP--and you're zapped
By Dragos Ruiu
October 21, 2002
ZDNet
You probably think your antivirus software can snare corrupt ZIP e-mail attachments. But you'd be dead wrong. Say hello to a newly discovered--and dangerous--quirk in the ZIP file format.
When everyone finds out about how this nasty new trait in ZIP file name handling can be exploited, something unseemly is going to hit the fan. Why? Because antivirus scanners can be conned, very simply, by ZIP files with excessively long names. And the code that makes it possible has been copied and incorporated by seemingly every big-name software company under the sun--not to mention its widespread use in security product update services.
This vulnerability was discovered by Mark Tesla and Chad Loder of Rapid7, a security software and consulting company that has created ZIP files that test how well different products deal with the long filenames the ZIP specification allows--and the news isn't encouraging. "Bzzt! Thank you for playing Security Bingo. Eliminated in this round are Microsoft, Apple, and IBM." All of these companies, and a host of others, make software that could be compromised by ZIP files. The application programmers have all made the same mistake of ignoring how the ZIP format works, using libraries and components that accommodate filenames only up to the OS maximum length (512 bytes for Windows, for example) instead of the 64K limit in the ZIP specification.
What's really alarming is the vulnerability to e-mail viruses. So far, every mail gateway virus scanner Rapid7 has tested lets a virus test file sneak right through if it's in a ZIP file with long filenames--the gateway scanners only catch the test files that are embedded in a "standard" ZIP file with short entry names.
Amazingly, the scanners don't assume a file is dangerous if they can't scan it--they choose instead to let it through and attach a message saying it's been scanned! So the user assumes the gateway has scanned the file, and has no qualms about opening it.
This problem is showing up all over--not just in operating systems and antivirus software. Many applications, such as Lotus Notes, can be compromised by ZIP files containing long filenames. Microsoft, which has been pretty reluctant to reveal who supplies its components, can at least pawn this one off on programmers at Inner Media, which has been happy to boast that Microsoft picked its product, DynaZip. Similarly, Apple can shrug and say, "Ask Alladin Systems." But regardless, Microsoft and Apple still have to patch the problem.
I'm not picking on DynaZip and Alladin. Other commercial library vendors like Verity are also vulnerable, as are open-source tools. No one is exempt from mistakes, and this is a very vivid example. Not planning for filenames exceeding the OS maximum length, even if the file format can handle longer, is apparently quite common. The coders at IBM picked a reliable ZIP library to use for Notes, only to mess up later on the file handling, for instance.
What's stupid is that this bug is a fairly fundamental error--exacerbated by "black-box" reuse of ZIP library code by rushing programmers. ("Just use this ZIP library. Don't worry about how it works--just have the code on my desk in the morning.")
It's been a painful lesson, slowly learned. Compression library issues show up often, such as the recent compression bug in the open-source zlib library that freed allocated memory twice. The problem is that countless closed-source software packages have borrowed concepts and reused code from the open-source zlib library. A little searching has some hope of tracking down the vulnerability in open-source software, but in closed-source stuff it's a potential nightmare unless the vendors take care of it. And a lot of vendors have used the ZIP compressed formats in their software packages. You'll have a difficult time figuring out who is using which libraries or who may have coded their own vulnerabilities. It's going to take a while to weed out.
I'm most concerned with update services for things like system software, antivirus packages, intrusion detection systems, firewalls, and other critical infrastructure systems, which all tend to make heavy use of ZIP archives. Some less cautiously designed systems automatically install and expand ZIP files sent over a network update service that doesn't have a human in the loop. I daresay, a couple of major vendors need to look at this immediately, and warn their users right away.
The impact of the news is twofold. For software vendors it's time to look through code again and find vulnerable libraries, and in turn to update users. On the flipside, users have to put those new shiny new bug-free code bits on their workstations and servers. No rest...
The moral of the story, once again, is: some up-front diligence when coding software can pay off big, and help avoid massive expenditures down the line. This latest class of ZIP file error is unfortunately destined to become a vivid example of that.
