The common cold of IT security

IT security experts are not ready to admit defeat by one of the most common types of exploits, but the battle against buffer overflows so far has produced about the same results as medical science has against the common cold: We can treat it, but we haven't found a way to cure it.

'It's the same problem over and over again,' independent security consultant Shawn Moyer said Thursday at the Black Hat Federal Briefings in Washington. 'We patch, we scan, we patch, we scan, and the cycles get shorter and shorter and the problem is worse.' The result, he said, is a 'flailing death spiral of updates and patches.'

There are defenses to block and mitigate these attacks, such as non-executable stacks and randomizing addresses within a system. None of them are bulletproof, but they do offer some relief.

A stack buffer overflow is one of the oldest tricks used by hackers to take control of a computer. When a malicious program writes excess data to an address on the call stack of an application with a fixed length buffer, the corrupted stack can make the application run improperly. Moyer described the technique as 'ten pounds of crap in a five pound bag.' This sometimes allows the exploiter to gain control by injecting executable code into the running program.

The problem is not new. Its roots go back to John von Neumann, a physicist who worked on the Manhattan Project during World War II and came up with some of the first ideas for reprogramming a computer without physically rewiring it. The possible threat it represents was recognized in the 1960s, and the first widely recognized Internet worm, the Morris worm, exploited buffer overflows in 1988.

'It's all basically the same problem for 20 years,' Moyer said.

One way to fight buffer overflows in the stack is to use non-executable stacks, which segregate executable instructions from other data. This is done in some systems, but often it is made optional because of the difficulties it can present in running applications. This means that even if the function is used, a worm could simply shut it off and gain the access it needs to execute code.

Another technique is adding extensions to the stack, 'guard values' or 'trip wires' that look for and halt unauthorized executables. Randomizing addresses in the stack also makes it more difficult for malicious code to find its intended target. This technique, while not necessarily killing the code, can at least slow it down and limit its spread. The technique is not easy to do well, however.

Microsoft's Vista is the first Windows operating system to natively support Address Space Layout Randomization, which puts programs and associated memory in random locations between reboots or executions, making them more difficult to attack because vulnerabilities are not found in predictable locations.

But it turns out that a tool used to randomize the addresses of data to hide it from hackers is not quite as random as it could be. Ollie Whitehouse, a security analyst with Symantec Corp., examined how information was distributed through the address space of Vista, and reported at last year's Black Hat Federal Briefings that some significant biases were discovered in address allocation for some functions, reducing the effectiveness of ASLR. This weakness is expected to be corrected in the first Service Pack release for Vista.

The Holy Grail of defense would to go to the root of the problem and fix it there, Moyer said. 'We could fix the code,' he added. 'That would be refreshing.'

It also is about as likely as doctors fixing our DNA to makes us immune from colds. The problem is that there is so much code to be examined and fixed that fixing it all is impossible, just as starting over from scratch with all new code for all of our software is impossible. Existing code can be scanned and sometimes fixed with automated tools. But even that has drawbacks.

'One of the problems with all of this is that it is going to break bad code,' which means that users tend to disable the tools so that applications can be used, Moyer said. For the foreseeable future, manual review of code probably will remain an important, if time-consuming, tool in the fight against buffer overflows.

About the Author

William Jackson is a Maryland-based freelance writer.

Stay Connected

Sign up for our newsletter.

I agree to this site's Privacy Policy.