Phd Defense: May 8th 2008
I would like to invite you to attend the public defense of my doctoral dissertation entitled:
"Efficient countermeasures for software vulnerabilities due to memory management errors", promoted by Prof. Dr. ir. W. Joosen and Prof. Dr. ir. F. Piessens.
The defense will take place on May 8th at 17h00 in the auditorium of the Department of Computer Science of the Katholieke Unversiteit Leuven:
Room 200A 00.225
Celestijnenlaan 200A
3001 Heverlee
A short description of how to get there can be found at:
http://www.cs.kuleuven.be/cs/algemene_info/plan/images/grondplancw.jpg
After the defense, there will be a small reception.
Abstract:
Despite many years of research and large investments by companies, the development of secure software is still a significant problem. This is evidenced by the steady increase in vulnerabilities that are reported year by year. Fast spreading worms like the Code Red worm, which caused an estimated worldwide economic loss of $2.62 billion, will often exploit implementation errors in programs to spread rapidly.
Vulnerabilities that can be exploited by attackers to perform code injection attacks are an important kind of implementation error. The Code Red worm exploited a buffer overflow to be able to run arbitrary code on the vulnerable machine, allowing it to spread by copying itself to the hosts it infected. The widespread use of C-like languages where such vulnerabilities are an important issue has exacerbated the problem.
In this dissertation we examine a number of vulnerabilities in C-like languages that can be exploited by attackers to perform code injection attacks and discuss countermeasures that provide protection against these kinds of attacks. This dissertation consists of three important parts: it starts off by presenting an extensive survey of current vulnerabilities and countermeasures, this is followed by a discussion of two novel countermeasures which aim to better protect against attacks on different vulnerabilities while having only a negligible impact on performance.
The survey provides a comprehensive and structured survey of vulnerabilities and countermeasures for code injection in C-like languages. Various countermeasures make different trade-offs in terms of performance, effectivity, memory cost, compatibility, etc. This makes it hard to evaluate and compare the adequacy of proposed countermeasures in a given context. This survey defines a classification and evaluation framework, on the basis of which advantages and disadvantages of countermeasures can be assessed. Based on the observations and the conclusions that were drawn from the survey, two countermeasures have been designed, implemented and evaluated.
The first countermeasure we present is an efficient countermeasure against stack smashing attacks. Our countermeasure does not rely on secret values (such as canaries) and protects against attacks that are not addressed by state-of-the-art countermeasures. Our technique splits the standard stack into multiple stacks. The allocation of data types to one of the stacks is based on the chances that a specific data element is either a target or source of attacks. We have implemented our solution in a C-compiler for Linux. The evaluation shows that the overhead of using our countermeasure is negligible.
The second countermeasure protects against attacks on heap-based buffer overflows and dangling pointer references. Overwriting the management information of the memory allocation library is often a source of attack on these vulnerabilities. All existing countermeasures with low performance overhead rely on magic values, canaries or other probabilistic values that must remain secret. In the case of magic values, a secret value is placed before a crucial memory location and by monitoring whether the value has changed, overruns can be detected. Hence, if attackers are able to read arbitrary memory locations, they can bypass the countermeasure. This countermeasure presents an approach that, when applied to a memory allocator, will protect against this attack vector without resorting to magic. We implemented our approach by modifying an existing widely-used memory allocator. Benchmarks show that this implementation has a negligible, sometimes even beneficial, impact on performance.
