Luxoft Training invites you to familiarize yourself with the translation of the article " C Secure Coding Rules: Past, Present, and Future " by Robert S. Sikord, Professor at the Institute of Software Engineering (SEI) Carnegie Mellon, author of The CERT® C Coding Standard, Second Edition and Secure Coding in C and C ++, Second Edition.

The CERT Safe Programming Initiative has been working on code writing standards since 2006. Programming Expert Robit C. Sikord, author of the book Safe Programming in C and C ++, talks about his contribution to this project, about the standard for safe coding in C ( ISO / IEC TS 17961) and discusses the future of these standards.

From the author of Secure Coding in C and C ++, 2nd Edition

Software development with secure coding standards is a good practice, and more recently, a requirement. Section 933 of the US National Defense Authorization Act (NDAA) of 2013. “Improving Software Purchased by the Department of Defense” requires evidence that organizations developing software for the public sector adhere to the standards of secure coding adopted by the Department of Defense (DoD) during development, updating and maintenance of software, as well as during inspection and evaluation.
')
Guidance on the technical implementation of security systems (STIG) for applications and the development process is constantly indicated as a requirement in the tender proposals (RFPs) of the Ministry of Defense. Section 2.1.5, Coding Standards, STIG requires the Project Manager to “control that the development team follows a set of code-writing standards.”

However, a number of problems make it difficult to meet these requirements:

• Developers do not adhere to coding standards that could be used to replace anti-patterns (unsafe code) with amenable and correct code;
• Analyzers do not use rules by which they can recognize security errors in the code;
• Analyzers must pass certification tests in order to be used as trusted programs.

For nearly a decade, the Secure Coding Initiative with CERT has worked to solve these problems, creating a guide to writing safe code for developers. CERT is also actively working with ISO / IEC in approving a basic set of requirements for suppliers of C analyzers and compilers who would like to diagnose unsafe code outside of the standards of that language. CERT is also developing a test suite to assess compliance with these requirements.

CERT safe coding standards are widely applied in the industry. At the SecCon conference in October 2011, Cisco Systems announced the adoption of the CERT standard for secure coding as a basic standard for product development. Recently, Oracle has integrated all CERT secure coding standards into its security standards. This was another step in the long-standing collaboration between CERT and Oracle: both organizations have already worked on developing secure coding standards for Java .

Past

I joined the C Standardization Committee (the official name of ISO / IEC JTC1 / SC22 / WG14) while working on the first edition of the book Safe Programming in C and C ++. At that time, WG14 was working on creating a document called C Library Security TR 24731, which was supposed to standardize the _s functions developed by Microsoft. I exchanged a few messages with Randy Meyers, who headed J11 (which then became PL22.11), about the strange behavior of the gets_s () function, which did not read the terminating line character. As a result, in the spring of 2005, I went to the WG14 meeting in Lillehammer (Norway) and since then CERT has been associated with the Committee for Standardization of the C Language.

NOTE
Working group PL22.11 is responsible for the technical development of a standard for the C programming language. This is a US technical advisory group under ISO / IEC JTC 1 SC22 / WG14.

At the WG14 meeting in spring 2006 in Berlin, Dr. Thomas Plum proposed to me the idea of ​​creating standards for secure CERT programming. The only analogue of this at that time was MISRA C : A Guide to Using C in Critical Systems (2004). However, this manual was intended for those systems where safety is in the first place, the requirements for which differ significantly from those for most systems, and hindered the use of language features approved by ISO / IEC 9899: 1999.

I immediately liked Tom's suggestion. The C language standard is an objectionable document with vague wording and difficult language, the main audience of which is compiler developers. The standard of safe coding would be aimed at programmers and would give practical recommendations on writing safe code in C.

The CERT secure coding standard was developed on the CERT Secure Coding wiki based on community development. Community experts, including members of the Committee for Standardization C, WG14 were invited to the project and have editing rights on the wiki. Community members can register on the wiki and leave comments on specific coding standards and individual rules.

Reviewers who left high-quality comments often received editorial privileges and were already directly involved in the development of programming standards. Today, the CERT Secure Coding wiki has 1374 authors.

The community development process has many advantages. The most important is that it allows a wide group of experts to form a unified opinion on the content of the rules. The main disadvantage of this type of development of coding standards is that the content of the standard is in a process of constant change. This is great if you need the most up-to-date information, and you realize that the latest change has not yet been finally checked. However, many software development companies require a static set of rules and guidelines that can be used as requirements in their development processes. To this end, we created a snapshot of the state of the standard two and a half years after the start of the community development and released it in a separate edition, The CERT C Secure Coding Standard (Addison-Wesley, 2008). The book covers version 1.0 of the standard. With the release of the manuscript in June 2008, version 1.0 (books) and the wiki version of the standard began to diverge.

The CERT C Secure Coding manual was first reviewed by the WG14 group at a meeting in London in April 2007, and then again in Kona (Hawaii) in August 2007.

The question of whether PL22.11 should submit the CERT Standard on Secure Coding to Group WG14 for publication as a technical report of type 2 or type 3 was discussed at the J11 / US TAG meeting on April 15, 2008, which is reflected in the meeting minutes. A preliminary vote was taken on the question “Who has time to work on this project?”, With a distribution of votes of 4 to 12. It was decided not to take any action. Later we were told that, despite the fact that the C Standard on Secure Coding is a serious set of recommendations developed with the help of many WG14 technical experts, WG14 itself does not provide recommendations to developers. However, WG14 was specifically engaged in developing regulatory requirements for tools, such as compilers.

Armed with this knowledge, we suggested that WG14 set up a working group to study the problem of creating a guide to safe coding in C. The first meeting of the working group took place on October 27, 2009. Thomas Plum acted as chairman, and I was elected to be the editor of the project. CERT introduced a set of implementable rules for secure coding in C to ISO / IEC for use in the standardization process.

David Keaton, acting chairman of PL22.11, subsequently replaced Tom in his post. Group members included suppliers of analyzers, such as Coverity, Fortify, GammaTech, Gimpel, Klocwork and LDRA; security experts; language experts and users. Finally, the question of developing and publishing a standard for secure coding in C / ISO / IEC TS 17961 was put in the action plan for the WG14 meeting in March 2012, and the working group was closed. Later Roberto Bagnara joined the editorial board, working at the Laboratory of Applied Formal Methods of the University of Parma and the company BUGSENG.

The present

The purpose of ISO / IEC TS 17961 is to enforce a basic set of requirements for analyzers, including static analysis tools, and C language compiler providers who would like to diagnose unsafe code outside of C standards. All rules are implemented through static analysis. The criterion for choosing the rules is that analyzers that implement these rules must effectively recognize errors in the security code without generating an excess of false results.

Currently, the use of static analysis to test security is carried out by different manufacturers in different ways, which leads to uneven coverage of serious problems. ISO / IEC TS 17961 contains safe coding rules and requires analyzers to recognize violations of these rules as a matter of conformance with specifications. The rules can be extended depending on the implementation, which gives users a guarantee of minimum coverage for any static analyzer that meets the requirements.

The ISO / IEC TS 17961 standard prescribes safe coding rules in C, and provides code examples. The standard does not describe the mechanism for applying these rules or a particular coding style. Each rule is accompanied by code examples. Examples of bad code are language constructs with potential security flaws; such code samples should be captured by standardized analyzers. Sample code examples should not be caught by analyzers.

The following table shows the relationship of ISO / IEC TS 17961 with other standards. Of all the publications listed, only ISO / IEC TS 17961 is intended for analyzers, not developers.

Coding standard	Standard C	Safety standard	Reliability standard	International standard	Whole language
CWE	Not all	Yes	Not	Not	N / A
MISRA C2	C89	Not	Yes	Not	Not
MISRA C3	C99	Not	Yes	Not	Not
Cert c99	C99	Yes	Not	Not	Yes
Cert c11	C11	Yes	Not	Not	Yes
ISO / IEC TS 17961	C11	Yes	Not	Yes	Yes

For each rule in the technical specification, a standard-compliant analyzer must issue a diagnostics when each case of violation of this rule is detected. If the text of a single program contains multiple simultaneous violations of the rules, the analyzer that meets the standard may issue an aggregated diagnostic and at least one diagnostic message. The diagnostic message may have the following form

Accessing freed memory in function abc, file xyz.c, line nnn. 

ISO / IEC TS 17961 does not require the analyzer to issue diagnostics for errors in the syntax or for the limitations of the Standard C language. We are talking only about source code that can be read by the analyzer. These rules do not apply to binary libraries and references to them.

An interesting aspect of the technical specification is the portability of assumptions, also known as the San Francisco Rule, because these assumptions were formulated at a meeting organized by Coverity at their head office. The San Francisco Rule states that a standard-compliant analyzer must recognize instances of violation of regulations for at least one implementation C, but is not required to recognize violations of a rule if the result is documented for the final implementation and does not create security flaws. Differences in the quality of implementation allow the analyzer to issue diagnostics for problems of portability. For example, for the following program fragment:

 long i; printf("i = %d", i); 

ISO / IEC TS 17961: 2013 (E) Information technology. Programming languages, their environment and software interface systems. Safe Coding Rules C ”was officially published in November 2013 and is available for purchase at an ISO standard store .

Among other things, The CERT®C Coding Standard, Second Edition has been corrected to comply with ISO / IEC TS 17961. Although these documents are intended for different audiences, consistency between documents should help developers use analyzers that comply with ISO / IEC TS 17961 to catch violations rules of this coding standard.

CERT also developed the Secure Coding Validation Suite , a test suite for validating the rules established by ISO / IEC TS 17961. These tests are based on examples of this technical specification and are distributed under a BSD license.

Future

The developers of static analyzers are working on creating analyzers that meet the requirements of ISO / IEC TS 17961. While this work is underway, we will continue to evaluate the effectiveness of the technical specification and try to understand whether it is necessary to prepare a second edition that will either eliminate the shortcomings of the published version or add new rules. for example, on non-standard behavior associated with the use of multithreading functions introduced in version C11.

As the C language and our knowledge of its safe use are constantly evolving, SEI will continue the SEI CERT C Coding Standard community development on secure coding wiki. These changes may later be included in the future official release of this standard. The new version will be sent to Addison-Wiley for publication.

Thanks

I express my gratitude to the reviewers who played a large role in this story: David Keaton, Thomas Plum, and John Benito.

Published with permission from Pearson Education.

November 26 and 27 Luxoft Training invites you to a master class by Robert S. Sikord dedicated to safe programming in C and C ++ languages.