CERT PODCAST SERIES: SECURITY FOR BUSINESS LEADERS: SHOW NOTES

Raising the Bar: Mainstreaming CERT C Secure Coding Rules

Key Message: CERT led the 7-year effort to publish an ISO/IEC technical specification containing 46 CERT-based secure coding rules for compilers and analyzers.

Executive Summary

"An essential element of secure coding in the C programming language is a set of well-documented and enforceable coding rules. The rules specified in this Technical Specification apply to analyzers, including static analysis tools, and C language compiler vendors that wish to diagnose insecure code beyond the requirements of the language standard. All rules are meant to be enforceable by static analysis. The application of static analysis to security has been done in an ad hoc manner by different vendors, resulting in nonuniform coverage of significant security issues. This specification enumerates secure coding rules and requires analysis engines to diagnose violations of these rules as a matter of conformance to this specification." [1]

In this podcast, Robert Seacord, the leader of CERT’s Secure Coding Initiative, discusses the 7-year journey resulting in the selection of 46 coding rules, derived from the CERT C Secure Coding Standard, for this new technical specification.

PART 1: HOW THE SPECIFICATION CAME TO BE AND ITS STRUCTURE

History

Foundational work for this effort started in 2005, captured in the book Secure Coding in C and C++. The following CERT team events led to the development of the technical specification:

2005: started working with the C standards committee
2006: approached with a request for CERT to develop secure coding standards for the C language
2009: presented the developed guidelines; told that the standards committee generally wasn’t in the habit of endorsing guidelines for end users – a setback.
2009+: suggested developing requirements for conforming analyzers, which was readily accepted; formed a study group
2009-2012: study group developed requirements as coding rules
2013: successfully balloted and published the technical specification

Technical Specification vs. Standard

Both can require millions of dollars in investment to comply so the C standards committee tends to be conservative.

Guidelines are often first published as technical specifications so that the affected industry has time to adjust, adapt, work with the content, identify problems, and provide feedback. Once this process is completed, technical specifications often become standards.

Structure and Objective

This specification is a collection of 46 coding rules. A conforming analyzer is required to issue a diagnostic if it detects a violation of any of these rules.

The C language standards have very little guidance on diagnosis. Warning and error messages are currently at the discretion of the compiler vendor so no consistent conformance is required.

The purpose of this specification is to raise the bar for conforming compilers and static analysis tools. It also provides users with a baseline that is guaranteed to find and diagnose the class of problems identified in the specification.

PART 2: VENDOR CONFORMANCE; SELECTING AND UPDATING CODING RULES

What a Vendor Needs to Do to Comply

ISO does not create conformance test suites that vendors can use to demonstrate that their tools conform with a particular standard or specification. This is typically left to the market and to vendors' self-assessment.

For this specification, CERT developed a conformance test suite called the Secure Coding Validation Suite that is available on GitHub. Vendors can use this suite to test their analyzer or compiler to ensure that they successfully diagnose the rule violations in the suite. It is distributed with a BSD-style license so it is publicly available.

Once vendors demonstrate that their tool conforms, they can make this claim.

How the 46 Coding Rules Were Selected

The team started with the rules in the CERT C secure coding standard. They made an initial determination of which rules could be analyzed. This content was provided to ISO and the study group was formed.

The study group spent three years discussing and reviewing candidate rules. Analyzer vendors argued to eliminate rules; users argued to keep rules. The following criteria were used to select and eliminate rules:

The first question asked about a rule was “What does this have to do with security?” The rule must check against programming flaws that have been known to result in vulnerabilities in ordinary, non-security code, such as those leading to a buffer overflow. Any defect in security-critical code (such as an encryption algorithm) constitutes a security violation but this may not be as high of a risk in ordinary code.
The second question asked about a rule was “How effectively can the rule be implemented?” Vendor concern was over high, false positive rates, as tools that report multiple violations when they do not exist would be rejected by users, developers, and customers. The study group decided to select rules that could be implemented with false positive rates at or below 20 percent.

Potential paths forward include a period of time while the specification is used and improved, followed by a second edition or an ISO decision to move directly to a standard if this is warranted by the community feedback.

PART 3: EXAMPLE CODING RULES AND RESOURCES FOR ADDRESSING VIOLATIONS

Coding Rule 5.30: Overflowing Signed Integers [intoflow]

From the specification:

"Whenever at least one operand is tainted, signed integer operations that trap and that can overflow shall be diagnosed."

Signed integer overflow is undefined behavior in the C language and users frequently misunderstand the consequences. One example of how this behavior manifests is as a buffer overflow.

The rule was contentious because it’s endemic in most C code that gets written today. For the specification, the rule is intended to diagnose signed integer operations that might trap as the result of one or more tainted inputs (those that are derived from untrusted external sources).

Coding Rule 5.22: Forming or Using Out-of-bounds Pointers or Array Subscripts [invptr]

From the specification:

"Using pointer arithmetic so that the result does not point into or just past the end of the same object, using invalid pointers in arithmetic expressions, or dereferencing pointers that do not point to a valid object shall be diagnosed."

"Likewise, using an array subscript so that the resulting reference does not refer to an element in the array also shall be diagnosed."

This rule requires that out-of-bounds pointers or array subscripts be diagnosed – not solely when reading or writing memory at an invalid pointer but, more importantly, resulting from the formation of the pointer itself, which is undefined behavior in the C language. Violations of this rule can also result in buffer overflows.

Addressing Diagnosed Violations

The specification is written for analyzers and compilers. The CERT C secure coding standard is written for developers. It contains examples that illustrate both noncompliant and compliant code. The compliant solutions are meant to be safe, security implementations of the same functionality that developers can use in their software.

Next Steps

The CERT team is still in contact with members of the study group and receiving incremental updates. The next set of expected announcements will be from vendors claiming full or limited compliance with the specification.

One member of the CERT team heads the U.S. delegation to the C standards committee, which is another source of coordination and feedback.

Resources

[1] ISO/IEC. "Information technology – Programming languages, their environments and system software interfaces – C secure coding rules." ISO/IEC TS 17961:2013(E), International Standards Organization, 2013.

Seacord, Robert. CERT C Secure Coding Standard. Addison-Wesley, 2008.

Seacord, Robert. Secure Coding in C and C++, Second Edition, Addison-Wesley, 2013.

CERT Secure Coding Initiative website

CERT Secure Coding Standards website

CERT podcast: "Cisco’s Adoption of CERT Secure Coding Standards," February 2012.

CERT podcast: "Mainstreaming Secure Coding Practices," March 2009.