Secure Coding Rules for C++ Copyright © 2016-2017 Curt Hill See https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=637 Copyright © 2016-2017 Curt Hill

CERT Computer Emergency Response Team A computer security group originally started by NSF Currently housed at Carnegie-Mellon University A part of this organization is the Software Engineering Institute (SEI) What follows is extracted from their coding standards Copyright © 2016-2017 Curt Hill

Aside I will not cover most of the rules They are very extensive Often use language features most of us are not familiar with Even me Many of these are in odd circumstances, where the language does not define what should happen They may not translate to a language with a tighter definition Most would fail the easy to understand code test Copyright © 2016-2017 Curt Hill

Areas of Concern Declarations and Initialization Expressions Integers and reals Arrays Characters and Strings Memory Management Input Output Miscellaneous Copyright © 2016-2017 Curt Hill

Declarations Avoid C-style variable number of parameters These end with an ellipsis to signify an unknown number of parameters Thus a function like: void multi(int x, …) { } The danger is determining the correct number and detecting problems if there is a conflict between what is told and what is given The development of fstreams was to avoid this Copyright © 2016-2017 Curt Hill

Declarations and Initialization Do not redefine a standard variable Such as cin or cout, but there are many others Not in C and not with preprocessor Treat memory allocation and deallocation as a pair Never overload one without the other in same block Do not throw exceptions in destructors or deallocation Copyright © 2016-2017 Curt Hill

Expressions Do not rely on order of evaluation for side effects Where is i incremented: a[++i] = i; Do not rely on side effects that may not be evaluated Recall short circuit evaluation A = 5; if (A > 4 || D++ < 3) Never use uninitialized memory int K; j = K*2; Copyright © 2016-2017 Curt Hill

Integers Ensure that unsigned integer operations do not wrap or that signed operations do not overflow Most arithmetic operations can cause Similarly, ensure that division and remainder operations do not result in divide-by-zero errors Ensure that integer conversions do not result in lost or misinterpreted data Concerns are casts (automatic or explicit), address modification and external values Copyright © 2016-2017 Curt Hill

Misinterpreted Data Consider the following: signed int a=-1; unsigned int b = 1; if(a<b) cout << “a is less than b”; else cout << “a is not less than b”; Unsigned is stronger than signed, thus a is cast. Because of the casting of signed to unsigned, a > b The comparison is between 1 and 4 billion something Copyright © 2016-2017 Curt Hill

Integers Again Do not shift an expression by a negative number of bits or by greater than or equal to the number of bits that exist in the operand Use correct integer precisions Never convert a pointer to integer or integer to pointer Copyright © 2016-2017 Curt Hill

Floating Point Do not use floating-point variables as loop counters Prevent or detect domain and range errors in math functions Ensure that floating-point conversions are within range of the new type Preserve precision when converting integral values to floating-point type An int is more precise than a float Copyright © 2016-2017 Curt Hill

Arrays Do not form or use out-of-bounds pointers or array subscripts Ensure size arguments for variable length arrays are in a valid range Do not subtract or compare two pointers that do not refer to the same array Do not add or subtract an integer to a pointer to a non-array object Guarantee that library functions do not form invalid pointers Copyright © 2016-2017 Curt Hill

Characters and Strings Do not attempt to modify string literals Guarantee that storage for strings has sufficient space for character data and the null terminator Do not pass a non-null-terminated character sequence to a library function that expects a string Do not confuse narrow and wide character strings and functions Copyright © 2016-2017 Curt Hill

Memory Management Do not access freed memory Free dynamically allocated memory when no longer needed Do not allocate and copy structures containing a flexible array member dynamically Only free memory allocated dynamically Allocate sufficient memory for an object Copyright © 2016-2017 Curt Hill

I/O Exclude user input from format strings Such as printf/scanf Use valid format strings Distinguish between characters read from a file and EOF Do not assume that fgets() or fgetws() returns a nonempty string when successful Copyright © 2016-2017 Curt Hill

I/O Do not copy a FILE object Recall the pointers present Reset strings on fgets() or fgetws() failure Close files when they are no longer needed Do not access a closed file Copyright © 2016-2017 Curt Hill

Miscellaneous Properly seed pseudorandom number generators Ensure that control never reaches the end of a non-void function Always end with a return Do not treat a predefined identifier as an object if it might only be implemented as a macro Do not call va_arg() on a va_list that has an indeterminate value Do not violate constraints Copyright © 2016-2017 Curt Hill

Summarizing Many of these are very obvious Part of idea of any of these is that checking code is provided around the use There are very many more such guidelines Your code review team should be familiar with these Having a syntax analyzer check these is usually required Copyright © 2016-2017 Curt Hill