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
Comments