The CERT C Secure Coding Standard

by Seacord, Robert C.

• ISBN13: 9780321563217
• ISBN10: 0321563212
• Edition: 1st
• Format: Paperback
• Copyright: 2008-10-14
• Publisher: Addison-Wesley Professional

Summary

"Irs"m an enthusiastic supporter of the CERT Secure Coding Initiative. Programmers have lots of sources of advice on correctness, clarity, maintainability, performance, and even safety. Advice on how specific language features affect security has been missing.The CERT reg; C Secure Coding Standardfills this need." -Randy Meyers, Chairman of ANSI C "For years we have relied upon the CERT/CC to publish advisories documenting an endless stream of security problems. Now CERT has embodied the advice of leading technical experts to give programmers and managers the practical guidance needed to avoid those problems in new applications and to help secure legacy systems. Well done!" -Dr. Thomas Plum, founder of Plum Hall, Inc. "Connectivity has sharply increased the need for secure, hacker-safe applications. By combining this CERT standard with other safety guidelines, customers gain all-round protection and approach the goal of zero-defect software." -Chris Tapp, Field Applications Engineer, LDRA Ltd. "Irs"ve found this standard to be an indispensable collection of expert information on exactly how modern software systems fail in practice. It is the perfect place to start for establishing internal secure coding guidelines. You wonrs"t find this information elsewhere, and, when it comes to software security, what you donrs"t know is often exactly what hurts you." -John McDonald, coauthor ofThe Art of Software Security Assessment Software security has major implications for the operations and assets of organizations, as well as for the welfare of individuals. To create secure software, developers must know where the dangers lie. Secure programming in C can be more difficult than even many experienced programmers believe. This book is an essential desktop reference documenting the first official release of The CERT reg; C Secure Coding Standard. The standard itemizes those coding errors that are the root causes of software vulnerabilities in C and prioritizes them by severity, likelihood of exploitation, and remediation costs. Each guideline provides examples of insecure code as well as secure, alternative implementations. If uniformly applied, these guidelines will eliminate the critical coding errors that lead to buffer overflows, format string vulnerabilities, integer overflow, and other common software vulnerabilities.

Author Biography

Robert C. Seacord leads the Secure Coding Initiative at the CERT at the Software Engineering Institute (SEI) in Pittsburgh, Pennsylvania. The CERT, among other security-related activities, regularly analyzes software vulnerability reports and assesses the risk to the Internet and other critical infrastructure. Robert is an adjunct professor in the Carnegie Mellon University School of Computer Science and in the Information Networking Institute and part-time faculty at the University of Pittsburgh. An eclectic technologist, Robert is author of three previous books, Secure Coding in C and C++ (Addison- Wesley, 2005), Building Systems from Commercial Components (Addison-Wesley, 2002), and Modernizing Legacy Systems (Addison-Wesley, 2003), as well as more than 40 papers on software security, componentbased software engineering, Web-based system design, legacy-system modernization, component repositories and search engines, and user interface design and development. Robert started programming professionally for IBM in 1982, working in communications and operating system software, processor development, and software engineering. Robert also has worked at the X Consortium, where he developed and maintained code for the Common Desktop Environment and the X Window System. He represents Carnegie Mellon at PL22. 11 (ANSI “C”) and is a technical expert for the JTC1/SC22/WG14 international standardization working group for the C programming language.

Table of Contents

Introduction
Hiv and Women's Reproductive Rights Reproductive Choice in the Age of AIDS -
Policy and Counselling Issues HIV Testing in Pregnancy -
HIV Transmission Risk An AIDS Risk Reduction Project with Inner-City Women -
Women's Consciousness in the Crack Culture
Women Providing Aids-Related Services Women Volunteers at Gmhc -
Paradoxical Practices -
Psychologists as Scientists in the Field of AIDS
Representations of Women and Aids Knowing Aids through the Televised Science Documentary
`With Champagne and Roses' -
Women at Risk from//in AIDS Discourse
Conclusion
Preface	p. xvii
Acknowledgments	p. xxxi
About the Author	p. xxxiii
Using This Standard	p. 1
System Qualities	p. 1
Automatically Generated Code	p. 2
Compliance	p. 3
Preprocessor (PRE)	p. 5
PRE00-C. Prefer inline or static functions to function-like macros	p. 6
PRE01-C. Use parentheses within macros around parameter names	p. 11
PRE02-C. Macro replacement lists should be parenthesized	p. 13
PRE03-C. Prefer type definitions to defines for encoding types	p. 15
PRE04-C. Do not reuse a standard header file name	p. 16
PRE05-C. Understand macro replacement when concatenating tokens or performing stringification	p. 18
PRE06-C. Enclose header files in an inclusion guard	p. 21
PRE07-C. Avoid using repeated question marks	p. 22
PRE08-C. Guarantee that header file names are unique	p. 24
PRE09-C. Do not replace secure functions with less secure functions	p. 26
PRE10-C. Wrap multistatement macros in a do-while loop	p. 27
PRE30-C. Do not create a universal character name through concatenation	p. 29
PRE31-C. Never invoke an unsafe macro with arguments containing assignment, increment, decrement, volatile access, or function call	p. 30
Declarations and Initialization (DCL)	p. 33
DCL00-C. const-qualify immutable objects	p. 35
DCL01-C. Do not reuse variable names in subscopes	p. 36
DCL02-C. Use visually distinct identifiers	p. 38
DCL03-C. Use a static assertion to test the value of a constant expression	p. 39
DCL04-C. Do not declare more than one variable per declaration	p. 42
DCL05-C. Use type definitions to improve code readability	p. 44
DCL06-C. Use meaningful symbolic constants to represent literal values in program logic	p. 45
DCL07-C. Include the appropriate type information in function declarators	p. 51
DCL08-C. Properly encode relationships in constant definitions	p. 54
DCL09-C. Declare functions that return an errno error code with a return type of errno_t	p. 57
DCL10-C. Maintain the contract between the writer and caller of variadic functions	p. 59
DCL11-C. Understand the type issues associated with variadic functions	p. 62
DCL12-C. Implement abstract data types using opaque types	p. 64
DCL13-C. Declare function parameters that are pointers to values not changed by the function as const	p. 66
DCL14-C. Do not make assumptions about the order of global variable initialization across translation units
Table of Contents provided by Publisher. All Rights Reserved.

Excerpts

An essential element of secure coding in the C programming language is well-documented and enforceable coding standards. Coding standards encourage programmers to follow a uniform set of guidelines determined by the requirements of the project and organization, rather than by the programmer's familiarity or preference. Once established, these standards can be used as a metric to evaluate source code (using manual or automated processes).The CERT C Secure Coding Standardprovides guidelines for secure coding in the C programming language. The goal of these guidelines is to eliminate insecure coding practices and undefined behaviors that can lead to exploitable vulnerabilities. The application of the secure coding standard will lead to higher-quality systems that are robust and more resistant to attack.The CERT C Secure Coding Standard was developed over a period of two and a half years as a community effort and involved the efforts of 226 contributors and reviewers including a half-dozen active members of the ISO/IEC WG14 international standardization working group for the programming language C, the Chairman and Vice Chairman of PL22.11 (ANSI "C"), representatives from the Open Group, USENIX, Microsoft, and numerous other companies and organizations. Drafts ofThe CERT C Secure Coding Standardwere twice reviewed by ISO/IEC WG14 and subjected to the scrutiny of the public including members of the Association of C and C++ Users (ACCU) and the comp.lang.c news group.The results of this effort are 89 rules and 132 recommendations for secure coding in the C programming language. Most of these guidelines come complete with insecure (non-compliant) code examples, and secure (compliant solutions). The CERT C Secure Coding Standards are supported by training available from the Software Engineering Institute and other licensed partners. A number of source code analysis tools are available to automatically detect violations of CERT Secure Coding Standard rules and recommendations, including Compass/ROSE which is freely available from Lawrence Livermore National Laboratory and CERT. The Demand for Secure SoftwareThe Morris worm incident, which brought ten percent of Internet systems to a halt in November 1988, resulted in a new and acute awareness of the need for secure software systems. Twenty years later, many security analysts, software developers, software users, and policy makers are asking the question "Why isn't software more secure?"The first problem is that the termsoftware security, as it is used today, is meaningless. I have attempted to define this term, as have others, but there is no generally accepted definition. Why does this matter?There are a variety of reasons given for why software is not more secure, such as the tools are inadequate, programmers lack sufficient training, and schedules are too short. But these are all solvable problems. The root cause of the issue lies elsewhere.The reason more software is not more secure is because there is nodemandfor secure software. In simple terms, if one vendor offers a product that has more features, better performance, and is available today and another vendor offers asecureproduct that has less features, not quite as good performance, and will be available in six months, there is really no question as to which product customers will buy, and vendorsknowthis.So why don't customers buy secure products? Again, it is because the word "secure" is meaningless in this context. Why would a customer pass up tangible benefits to buy a product that has an ill-defined and intangible property?This is the problem addressed by the CERT C Secure Coding Standard. This book contains 89 rules and 132 recommendations for producing secure code. While the application of these rules and recommendations does not guarantee the security of a software system, it does tell you a gr