Secure C++

C++, while full of safety features, still exposes a ton of insecure features inherited from C, and to be fair, isn’t designed to be as safe as it could be. There are still dozens and dozens of practices the C++ programmer needs to adopt to write secure code.

Background

These notes will assume you’re a fairly capable C++ programmer. In particular, you should already know:

CERT-C++

The The SEI CERT C++ Coding Standard is a work-in-progress document from the Software Engineering Institute at Carnegie Mellon. (Before diving into it, you might want to check out this short blog post about the SEI guidelines.)

The Standard is organized into a number of Guidelines, divided into Rules and Recommendations, grouped into sections numbered and titled as follows:

Rules are basically requirements that if violated will almost surely result in an exploitable vulnerability. They are generally in principle checkable by static analysis tools (or by a competent human code reviewer). Recommendations basically improve software quality, but violations are not necessarily defects.

The online standard has a page listing all of the rules. As of summer, 2021, the standard does not have any published recommendations; they were removed in 2019 pending a review. Who knows when they will be back.

CLASSWORK
We’re going to browse a few of these guidelines!

ISO C++ Coding Standards

The Standard C++ Foundation maintains a wiki called the C++ Super-FAQ, and on this wiki there’s a very helpful page on coding standards.

Coding standards are helpful for security.

The foundation recommends three good sources:

They also recommend avoiding old or ad-hoc coding standards. Many standards out there just pile some stuff on top of C, or are just so old they don't even understand Modern C++. Interestingly, the foundation did not call out CERT C++ as a recommended guide, nor did they recommend the Google C++ Style Guide.

The sections in the the C++ Core Guidelines cover the usual suspects:

Each section has a number of different items, with rationales, examples, and non-examples. Here’s one of the items from the Philosophy section:

P.1: Express ideas directly in code

This item has examples and non-examples, including:

class Date {
public:
    Month month() const;      // good
    int month();              // bad
    // ...
};

void change_speed(double s)   // bad: what does s signify?

void change_speed(Speed s)    // better: the meaning of s is specified

change_speed(2.3);            // error: no unit
change_speed(23_m / 10s);     // meters per second

Wondering about that syntax in the last example?

Sounds familiar right? This is something we’ve been talking about since the beginning of this course. It’s really no surprise that this is the first item in the guide.

CLASSWORK
Let’s browse these guidelines, and for those that don’t specifically mention security implications, let’s think about how non-examples can lead to vulnerabilities.

Summary

We’ve covered:

  • CERT C++
  • ISO C++ Coding Standards