Conclusions

 [Previous Chapter]  [Previous Page]  [Contents]  [Next Page]

*Each vulnerability which allows us to modify memory areas beyond some input variable, opens the threat that some jump address (usually return addresses) can be manipulated to execute malicious code which has been loaded in some buffer.
 
*Exploits will be developed for known vulnerabilities even if it can be at times pretty challenging.
 
*The standard C library provides many functions which modify a string without knowing its length (examples: strcat, sprintf). It took some time until alternative variants with length parameters became available.
 
*Security fixes attempted in many cases to limit the input and to use some estimates of the maximal length if the input was used elsewhere. Many software authors trusted their calculations and continued with the traditional programming style. Unfortunately, many of these estimates were simply wrong and allowed future exploits.
 
*Consequently, buffer limits should be verified everywhere.
 
*If the C programming language cannot be avoided, it is best to forget the C standard library and buffers of limited length. Instead, libraries that support dynamic strings should be taken. The only author of network services who does this thoroughly is Dan J. Bernstein (Qmail, djbdns).
See http://cr.yp.to/
 

 [Previous Chapter]  [Previous Page]  [Contents]  [Next Page]
Copyright © 2001, 2002 Andreas Borchert, converted to HTML on April 07, 2002