Legal Notice This page last changed on Sep 10, 2007 by rcs. CERT C Programming Language Secure Coding Standard Document No. N1255 September 10, 2007 Legal Notice This document represents a preliminary draft of the CERT C Programming Language Secure Coding Standard. This project was initiated following the 2006 Berlin meeting of WG14 to produce a secure coding standard based on the C99 standard. Although this is an incomplete work, we would greatly appreciate your comments and feedback at this time to further the development and refinement of the material. Please provide comments that are commensurate with the existing detail in the document. For example, if a rule or recommendation is simply a stub you may wish to comment if you think having a rule or recommendation in that area is unwarranted. This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense. Copyright 2007 Carnegie Mellon University. NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and "No Warranty" statements are included with all reproductions and derivative works. External use. Requests for permission to reproduce this document or prepare derivative works of this document for external and commercial use should be addressed to the SEI Licensing Agent. This work was created in the performance of Federal Government Contract Number F19628-00-C-0003 Document generated by Confluence on Sep 10, 2007 13:11 Page 8 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at 252.227-7013. Document generated by Confluence on Sep 10, 2007 13:11 Page 9 Acknowledgements This page last changed on Aug 07, 2007 by rcs. Thanks to everyone who contributed to making this effort a success. Contributors Juan Alvarado, Hal Burch, Stephen C. Dewhurst, Chad Dougherty, Mark Dowd, William Fithen, Jeffrey Gennari, Shaun Hedrick, Fred Long, John McDonald, Justin Pincar, Thomas Plum, Dan Saks, Robert C. Seacord. Reviewers Jerry Leichter, Scott Meyers, Ron Natalie, Dan Plakosh, Michel Schinz, Eric Sosman, Andrey Tarasevich, Henry S. Warren, and Ivan Vecerina. Editors Jodi Blake, Pamela Curtis Developers and Administrators Rudolph Maceyko, Jason McCormick, Joe McManus, Brad Rubbo Special Thanks Jeff Carpenter, Jason Rafail, Frank Redner Document generated by Confluence on Sep 10, 2007 13:11 Page 11 CERT C Programming Language Secure Coding Standard This page last changed on Jun 14, 2007 by jpincar. 00. Introduction 01. Preprocessor (PRE) 02. Declarations and Initialization (DCL) 03. Expressions (EXP) 04. Integers (INT) 05. Floating Point (FLP) 06. Arrays (ARR) 07. Strings (STR) 08. Memory Management (MEM) 09. Input Output (FIO) 10. Temporary Files (TMP) 11. Environment (ENV) 12. Signals (SIG) 13. Miscellaneous (MSC) 50. POSIX 99. The Void AA. C References BB. Definitions Document generated by Confluence on Sep 10, 2007 13:11 Page 12 00. Introduction This page last changed on Mar 20, 2007 by [email protected]. 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 rules and 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). Scope Rules Versus Recommendations Development Process Usage System Qualities Priority and Levels Identifiers Document generated by Confluence on Sep 10, 2007 13:11 Page 13 Development Process This page last changed on Mar 20, 2007 by [email protected]. The development of a secure coding standard for any programming language is a difficult undertaking that requires significant community involvement. The following development process has been used to create this standard: 1. Rules and recommendations for a coding standard are solicited from the communities involved in the development and application of each programming language, including the formal or de facto standard bodies responsible for the documented standard. 2. These rules and recommendations are edited by senior members of the CERT technical staff for content and style and placed on the CERT Secure Coding Standards web site for comment and review. 3. The user community may then comment on the publically posted content using threaded discussions and other communication tools. Once a consensus develops that the rule or recommendation is appropriate and correct, the final rule is incorporated into the coding standard. Drafts of the CERT C Programming Language Secure Coding Standard are reviewed by the ISO/IEC JTC1/SC22/WG14 international standardization working group for the C programming language and other industry groups as appropriate. Document generated by Confluence on Sep 10, 2007 13:11 Page 14 Identifiers This page last changed on Mar 20, 2007 by [email protected]. Each rule and recommendation is given a unique identifier within a standard. These identifiers consist of three parts: • A three letter mneumonic representing the section of the standard • A two digit numeric value in the range of 00-99 • The letter "A" or "C" to indicate whether the coding practice is an advisory recommendation or a compulsory rule The three letter mneumonic can be used to group similar coding practices and to indicate to which category a coding practice belongs. The numeric value is used to give each coding practice a unique identifier. Numeric values in the range of 00-29 are reserved for recommendations, while values in the range of 30-99 are reserved for rules. The letter "A" or "C" in the identifier is not required to uniquely identify each coding practice. It is used only to provide a clear indication of whether the coding practice is an advisory recommendation or a compulsory rule. Document generated by Confluence on Sep 10, 2007 13:11 Page 15 Priority and Levels This page last changed on Mar 20, 2007 by [email protected]. Each rule and recommendation in a secure coding standard has an assigned priority. Priorities are assigned using a metric based on Failure Mode, Effects, and Criticality Analysis (FMECA) [IEC 60812]. Three values are assigned for each rule on a scale of 1 - 3 for • severity - how serious are the consequences of the rule being ignored 1 = low (denial-of-service attack, abnormal termination) 2 = medium (data integrity violation, unintentional information disclosure) 3 = high (run arbitrary code) • likelihood - how likely is it that a flaw introduced by ignoring the rule could lead to an exploitable vulnerability 1 = unlikely 2 = probable 3 = likely • remediation cost - how expensive is it to comply with the rule 1 = high (manual detection and correction) 2 = medium (automatic detection / manual correction) 3 = low (automatic detection and correction) The three values are then multiplied together for each rule. This product provides a measure that can be used in prioritizing the application of the rules. These products range from 1 to 27. Rules and recommendations with a priority in the range of 1-4 are level 3 rules, 6-9 are level 2, and 12-27 are level 1. As a result, it is possible to claim level 1, level 2, or complete compliance (level 3) with a standard by implementing all rules in a level, as shown in the following illustration: Document generated by Confluence on Sep 10, 2007 13:11 Page 16 Recommendations are not compulsory and are provided for information purposes only. The metric is designed primarily for remediation projects. It is assumed that new development efforts will conform with the entire standard. Document generated by Confluence on Sep 10, 2007 13:11 Page 17 Rules Versus Recommendations This page last changed on Aug 29, 2007 by rcs. This secure coding standard consists of rules and recommendations. Coding practices are defined to be rules when all of the following conditions are met: 1. Violation of the coding practice will result in a security flaw that may result in an exploitable vulnerability. 2. There is an enumerable set of exceptional conditions (or no such conditions) in which violating the coding practice is necessary to ensure the correct behavior for the program. 3. Conformance to the coding practice can be verified. Rules must be followed to claim compliance with this standard unless an exceptional condition exists. If an exceptional condition is claimed, the exception must correspond to a predefined exceptional condition and the application of this exception must be documented in the source code. Recommendations are guidelines or suggestions. Coding practices are defined to be recommendations when all of the following conditions are met: 1. Application of the coding practice is likely to improve system security. 2. One or more of the requirements necessary for a coding practice to be considered a rule cannot be met.