Nontrivial C++ programs are generally divided into multiple translation units that are later linked together to form an executable. To support such a model, C++ restricts named object definitions to ensure that linking will behave deterministically by requiring a single definition for an object across all translation units. This model is called the one-definition rule (ODR), which is defined by the C++ Standard, [basic.def.odr], in paragraph 4 [ISO/IEC 14882-2014].:
Every program shall contain exactly one definition of every non-inline function or variable that is odr-used in that program; no diagnostic required. The definition can appear explicitly in the program, it can be found in the standard or a user-defined library, or (when appropriate) it is implicitly-defined. An inline function shall be defined in every translation unit in which it is odr-used.
The most common approach to multitranslation unit compilation involves declarations residing in a header file that is subsequently made available to a source file via #include
. These declarations are often also definitions, such as class and function template definitions. This approach is allowed by an exception defined in paragraph 6, which, in part, states the following:
...
Violating the ODR causes undefined behavior, which can result in exploits as well as denial-of-service attacks. As shown in "Support for Whole-Program Analysis and the Verification of the One-Definition Rule in C++" [Quinlan 06], failing to enforce the ODR enables a virtual function pointer attack known as the VPTR exploit. In this exploit, an object's virtual function table is corrupted so that calling a virtual function on the object results in malicious code being executed. See the paper by Quinlan and colleagues for more details. However, note that to introduce the malicious class, the attacker must have access to the system building the code.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
DCL60-CPP | High | Unlikely | High | P3 | L3 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| type-compatibility definition-duplicate undefined-extern undefined-extern-pure-virtual external-file-spreading type-file-spreading | Partially checked | ||||||
Axivion Bauhaus Suite |
| CertC++-DCL60 | |||||||
CodeSonar |
| LANG.STRUCT.DEF.FDH | Function defined in header file Object defined in header file | ||||||
Helix QAC |
| C++1067, C++1509, C++1510 | |||||||
LDRA tool suite |
| 286 S, 287 S | Fully implemented |
Parasoft C/C++test |
|
1509
| CERT_CPP-DCL60-a | A class, union or enum name (including qualification, if any) shall be a unique identifier | |||||||
Polyspace Bug Finder |
| CERT C++: DCL60-CPP | Checks for inline constraints not respected (rule partially covered) | ||||||
RuleChecker |
| type-compatibility definition-duplicate undefined-extern undefined-extern-pure-virtual external-file-spreading type-file-spreading | Partially checked |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Bibliography
...
...