In order to assess the detection capability of our heap protection scheme, we attempted to run real-world exploits against several vulnerable programs. These included:

• wu-ftpd file globbing heap corruption vulnerability in wuftpd 2.6.0
• sudo password prompt heap overflow vulnerability in sudo 1.6.3
• cvs directory request double free heap corruption vulnerability in cvs 1.11.4

In addition, we included several proof-of-concept exploits to demonstrate that the existing debugging code present in the glibc heap management routines are not suitable for heap protection.

Exploit	glibc	glibc + debugging	glibc + heap protection
wu-ftpd	shell	aborted	aborted
sudo	shell	aborted	aborted
cvs	segfault	aborted	aborted
debug evasion	shell	shell	aborted

From the above table, one can see that in almost all cases, heap vulnerabilities in common programs were easily exploited using available tools. One can also see that glibc with our heap protection applied successfully detected and prevented all of the exploits we tested, while glibc's debugging code was open to evasion.

To evaluate the performance impact of our heap protection scheme, a series of micro- and macro-benchmarks were run. All systems utilized in the following performance benchmarks were Intel Pentium 4 1.8 GHz machines with 1 GiB of RAM running RedHat Linux 8.0 with 3COM 905C-TX NICs.



To measure the expected worst-case impact upon user applications, we wrote a simple micro-benchmark that allocates and frees 222 memory chunks of random sizes between 0 and 1024 bytes in a tight loop. The maximum size of 1024 was chosen to obtain a balanced distribution of objects in dedicated bins and objects in bins that cover a range of difference sizes. We also utilized the dynamic memory allocation benchmark from the AIM9 test suite. The following table depicts the results for glibc, glibc with debugging enabled, and glibc with our heap protection patch applied.

Benchmark	glibc	glibc + debugging	glibc + heap protection
loop	1587	2621 (+65%)	2033 (+28%)
AIM9	5094	7603 (+49%)	5338 (+5%)

From the above table, one can see that our heap protection patch does incur a worst-case overhead of 30%. However, in the AIM9 benchmark, one sees that we only incur a 5% overhead. For both benchmarks, glibc's debugging routines incurred significantly more overhead than our system.



To determine the overhead our heap protection system would incur in some examples of real-world applications, we ran the OSDB benchmark as well as Mindcraft's WebStone webserver benchmark on an unpatched glibc and glibc with our heap protection system applied. The following table depicts the results of the OSDB 0.15.1 benchmark for a PostgreSQL 7.2.3 database.

Benchmark	glibc	glibc + heap protection
ODSB	6015	6070 (+0.91%)

Clearly, in this case, the overhead incurred is not significant.



For the WebStone benchmark, average HTTP client response time and throughput were measured for both unpatched glibc and glibc with our heap protection patch applied. The webserver utilized was Apache 2.0.40, with the number of clients ranged from 20 to 100 in intervals of 10.



















From the above graphs, one can see that there is virtually no impact on either response times or throughput.



In conclusion, though our approach does incur a certain amount of overhead, we claim that it is tolerable for most real-world applications and is compensated for by the increase in security.