1. Secure Coding Rules for C++ Copyright © 2016-2017 Curt Hill
See
Copyright © Curt Hill

2. 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 © Curt Hill

3. 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 © Curt Hill

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

5. 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 © Curt Hill

6. 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 © Curt Hill

7. 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 © Curt Hill

8. 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 © Curt Hill

9. 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 © Curt Hill

10. 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 © Curt Hill

11. 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 © Curt Hill

12. 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 © Curt Hill

13. 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 © Curt Hill

14. 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 © Curt Hill

15. 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 © Curt Hill

16. 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 © Curt Hill

17. 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 © Curt Hill

18. 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 © Curt Hill