Why don’t we have tools for this vulnerability?
Our February Security Advisor column is on buffer overflows. As usual, Maggie Biggs does a great job explaining a highly technical subject in lay terms without watering down the technical analysis. I assigned the piece because I thought the problem deserved more attention than it gets. And, while I have read hundreds of technical bulletins warning of buffer overflow vulnerabilities, I didn’t have a clear picture of how the problem manifests itself in everyday network environments. Since I suspected the same was true for most of our readers, it made sense to ask Maggie to write the piece.
As I edited the piece this afternoon, two things struck me. First, my intuitions were correct. Buffer overflows are a far more pervasive problem than previously reported elsewhere. Maggie’s research indicates that more than half of all computer security breaches are the result of buffer overflows. And, unlike with viruses or port network attacks, administrators don’t have tools to help them defend their networks against buffer overflows, at least not beyond vigilance backed by simple policies and procedures. Second, the information is too important to wait for our normal editing cycle to publish. But instead of publishing the report in full today, I will give a quick synopsis. It may not be as complete or intelligible as Maggie’s story, but it hopefully will help raise awareness of the problem and prevent security breaches between now and February.
Generally speaking, a buffer overflow is a programming error that occurs when a program tries to write too much data into an assigned temporary memory address, or buffer. When the data overflows the buffer’s size, it can spill into adjacent memory addresses and corrupt that data. When Internet-related programs use buffers for temporary data (and most do), a hacker can exploit them by sending data that deliberately overflows the buffer. The spill is typically written to contain executable code that can then be run when the program accesses the adjacent memory addresses. Buffer overflow vulnerabilities are typically not detected until a security breach reveals their existence. Then the vendor issues a patch that prevents the program from writing too much data to the specific address.
As I indicated, there’s nothing like Norton to look at all the programs running on a computer system and detect whether any of them are vulnerable to recently discovered buffer overflows. I would think it a huge challenge to develop such a tool, since there are hundreds of Internet programs on dozens of operating systems that could be vulnerable. Still, given the market demand, you would think someone was at least working on a solution. If readers know of such research, please let me know and I’ll post it in a forthcoming column.
Until such a solution is developed, all you can do is to educate yourself about the software installed in your enterprise that connects to the Internet. Besides vendors’ sites, which should contain buffer overflow patches created since your last upgrade, a good place to find information on this vulnerability is the CERT Coordination Center mailing list, which issues reports every time a new vulnerability is discovered. Unfortunately, it sometimes takes the vendors a few days to acknowledge the problem, let alone issue a patch. In that time frame, your enterprise can be extremely vulnerable to hackers who also monitor the list and try to probe networks for the very same vulnerability.
It’s a sobering reality. Until Symantec or some similar vendor develops a tool to secure networks against these vulnerabilities, there is no real defense against the problem. Now I know what they mean when hackers tell me, “You have no idea how easy it is to hack into some companies.” Most of the time, they’re referring to companies that fail to apply existing patches for known vulnerabilities. But even if you do apply those patches, you’re potentially at risk for as-yet-unknown buffer overflow vulnerabilities.
James Mathewson is editor of ComputerUser magazine and ComputerUser.com