01.07.2016 Views

SEI CERT C Coding Standard

tqcylJ

tqcylJ

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Introduction - Rules Versus Recommendations<br />

continues using an in-domain value in place of the original. In termination, the program logic terminates<br />

the path of execution when an out-of-domain value is detected, often simply by branching<br />

around whatever code would have used the value.<br />

In general, sanitization cannot be recognized exactly using static analysis. Analyzers that perform<br />

taint analysis usually provide some extralinguistic mechanism to identify sanitizing functions that<br />

sanitize an argument (passed by address) in place, return a sanitized version of an argument, or<br />

return a status code indicating whether the argument is in the required domain. Because such extralinguistic<br />

mechanisms are outside the scope of this coding standard, we use a set of rudimentary<br />

definitions of sanitization that is likely to recognize real sanitization but might cause nonsanitizing<br />

or ineffectively sanitizing code to be misconstrued as sanitizing.<br />

The following definition of sanitization presupposes that the analysis is in some way maintaining<br />

a set of constraints on each value encountered as the simulated execution progresses: a given path<br />

through the code sanitizes a value with respect to a given restricted sink if it restricts the range of<br />

that value to a subset of the defined domain of the restricted sink type. For example, sanitization<br />

of signed integers with respect to an array index operation must restrict the range of that integer<br />

value to numbers between zero and the size of the array minus one.<br />

This description is suitable for numeric values, but sanitization of strings with respect to content is<br />

more difficult to recognize in a general way.<br />

1.7 Rules Versus Recommendations<br />

This coding standard contains 99 coding rules. The <strong>CERT</strong> <strong>Coding</strong> <strong>Standard</strong>s wiki also has 185<br />

recommendations at the time of this writing. Rules are meant to provide normative requirements<br />

for code; recommendations are meant to provide guidance that, when followed, should improve<br />

the safety, reliability, and security of software systems. However, a violation of a recommendation<br />

does not necessarily indicate the presence of a defect in the code. Rules and recommendations<br />

are collectively referred to as guidelines.<br />

The wiki also contains two platform-specific annexes at the time of this writing; one annex is for<br />

POSIX and the other one is for Windows. These annexes have been omitted from this standard<br />

because they are not part of the core standard.<br />

This standard is based on the C rules available on the <strong>CERT</strong> Secure <strong>Coding</strong> wiki as of 30 March<br />

2016.<br />

1.7.1 Rules<br />

Rules must meet the following criteria:<br />

1. Violation of the guideline is likely to result in a defect that may adversely affect the safety,<br />

reliability, or security of a system, for example, by introducing a security flaw that may result<br />

in an exploitable vulnerability.<br />

<strong>SEI</strong> <strong>CERT</strong> C <strong>Coding</strong> <strong>Standard</strong>: Rules for Developing Safe, Reliable, and Secure Systems 10<br />

Software Engineering Institute | Carnegie Mellon University<br />

[DISTRIBUTION STATEMENT A] Approved for public release and unlimited distribution.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!