[ISN] The common cold of IT security

alerts@private

http://www.gcn.com/online/vol1_no1/45864-1.html

By William Jackson
GCN.com
02/22/08 

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 havent found a way to cure it.

Its 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.

Its 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.

Microsofts 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 years 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.

___________________________________________________      
Subscribe to InfoSec News
http://www.infosecnews.org/mailman/listinfo/isn 