The C programming language
AMAST '02 Proceedings of the 9th International Conference on Algebraic Methodology and Software Technology
Countering code-injection attacks with instruction-set randomization
Proceedings of the 10th ACM conference on Computer and communications security
Preventing privilege escalation
SSYM'03 Proceedings of the 12th conference on USENIX Security Symposium - Volume 12
Systematically Eradicating Data Injection Attacks Using Security-Oriented Program Transformations
ESSoS '09 Proceedings of the 1st International Symposium on Engineering Secure Software and Systems
Security-oriented program transformations
Proceedings of the 5th Annual Workshop on Cyber Security and Information Intelligence Research: Cyber Security and Information Intelligence Challenges and Strategies
Cause clue clauses: error localization using maximum satisfiability
Proceedings of the 32nd ACM SIGPLAN conference on Programming language design and implementation
Runtime countermeasures for code injection attacks against C and C++ programs
ACM Computing Surveys (CSUR)
GHUMVEE: efficient, effective, and flexible replication
FPS'12 Proceedings of the 5th international conference on Foundations and Practice of Security
Hi-index | 0.00 |
As the prevalence of buffer overflow attacks has increased, more and more programmers are using size or length-bounded string functions such as strncpy() and strncat(). While this is certainly an encouraging trend, the standard C string functions generally used were not really designed for the task. This paper describes an alternate, intuitive, and consistent API designed with safe string copies in mind. There are several problems encountered when strncpy() and strncat() are used as safe versions of strcpy() and strcat(). Both functions deal with NUL-termination and the length parameter in different and non-intuitive ways that confuse even experienced programmers. They also provide no easy way to detect when truncation occurs. Finally, strncpy() zero-fills the remainder of the destination string, incurring a performance penalty. Of all these issues, the confusion caused by the length parameters and the related issue of NUL-termination are most important. When we audited the OpenBSD source tree for potential security holes we found rampant misuse of strncpy() and strncat(). While not all of these resulted in exploitable security holes, they made it clear that the rules for using strncpy() and strncat() in safe string operations are widely misunderstood. The proposed replacement functions, strlcpy() and strlcat(), address these problems by presenting an API designed for safe string copies (see Figure 1 for function prototypes). Both functions guarantee NUL-termination, take as a length parameter the size of the string in bytes, and provide an easy way to detect truncation. Neither function zero-fills unused bytes in the destination.