Thomas Plum, [email protected]
Robert Seacord, [email protected]
WG23 (Programming Language Vulnerabilities) has proposed TR 24772 ("Guidelines to avoiding vulnerabilities in language selection and use") which is currently under PDTR ballot. [24772] Here is section 1.4 of that document:
|
1.4 Intended Audience The intended audiences for this Technical Report are those who are concerned with assuring the software of their system, that is; those who are developing, qualifying, or maintaining a software system and need to avoid vulnerabilities that could cause the software to execute in a manner other than intended. As described in the following paragraphs, developers of applications that have clear safety, security or mission criticality are usually aware of the risks associated with their code and can be expected to use this document to ensure that all relevant aspects of their development language have been controlled. That should not be taken to mean that other developers could ignore this document. A flaw in an application that of itself has no direct criticality may provide the route by which an attacker gains control of a system or may otherwise disrupt co-located applications that are safety, security or mission critical. It would be hoped that such developers would use this document to ensure that common vulnerabilities are removed from all applications. 1.4.1 Safety-Critical Applications Users who may benefit from this document include those developing, qualifying, or maintaining a system where it is critical to prevent behaviour, which might lead to: � loss of human life or human injury, or � damage to the environment and where it is justified to spend additional resources to maintain this property. 1.4.2 Security-Critical Applications Users who may benefit from this document include those developing, qualifying, or maintaining a system where it is critical to exhibit security properties of: � confidentiality � integrity, and � availability and where it is justified to spend additional resources to maintain those properties. 1.4.3 Mission-Critical Applications Users who may benefit from this document include those developing, qualifying, or maintaining a system where it is critical to prevent behaviour that might lead to: � property loss or damage, or � economic loss or damage. 1.4.4 Modeling and Simulation Applications People who may benefit from this document include those who are primarily experts in areas other than programming but need to use computation as part of their work. Such people include scientists, engineers, economists, and statisticians. They require high confidence in the applications they write and use because of the increasing complexity of the calculations made (and the consequent use of teams of programmers each contributing expertise in a portion of the calculation), or to the costs of invalid results, or to the expense of individual calculations implied by a very large number of processors used and/or very long execution times needed to complete the calculations. These circumstances give a consequent need for high reliability and motivate the need felt by these programmers for the guidance offered in this document. |
Paper WG14/N1344 was discussed at the Milpitas meeting. There was general agreement that the ability to analyze program behavior by studying the source code (i.e., "source-code causality") is of importance to many audiences, including the four audiences identified above. Furthermore, if "ordinary" undefined behaviors are permitted to create "wobbly" results, source-code causality is lost. In email contributions, Joseph Myers had suggested that a compiling mode that preserves source-code causality would be different in various ways from some current optimization practice; such a mode might be called a "security profile". However, several members of WG14 noted that the name "profile" designates a specific heavyweight document and process in ISO, and that an ordinary Annex to C1x might suffice for the purposes discussed here.
We therefore will propose to add one C1x annex presenting compiler-plus-library solutions for the problems raised in the prior discussions.
The actual title for the annex might be one of the last decisions to be made: let's first agree on the contents, and then we can pick the title. The word "vulnerability" is a negative word that defines the problem; presumably we want a positive word that characterizes some aspects of the solution. For now, we suggest "Analyzability", because there seemed to be general agreement at Milpitas that the ability to analyze the C source was essential to all the audiences listed by WG23. An implementation is operating in "analyzable mode" if it implements the features described in the Analyzability Annex.
The final annex in 9899:1999 was Annex J, so the new annex could become annex K. The first component in this Annex K could be the Bounds-Checking Library ("BCL", TR 24731-1). The goals of the BCL are obviously important to the Annex K audience. [BCL]
The Dynamic Allocation functions listed in TR 24731 Part 2 could also be listed in Annex K. One concern here is that these functions are of course already an established part of some ISO standards, and Nick Stoughton has indicated that there is strong opposition to any process that would produce changes in their spec. (This question of including 24731-2 is independent of the rest of this paper.) [TR-2]
For now, we propose that Annex K be Informative. Other categories are possible, but let's first determine the contents and then we can consider the appropriate category.
Note that C99 has definitions for value, implementation-defined value, indeterminate value, and unspecified value:
3.17
1 value
precise meaning of the contents of an object when interpreted as having a specific type
3.17.1
1 implementation-defined value
unspecified value where each implementation documents how the choice is made
3.17.2
1 indeterminate value
either an unspecified value or a trap representation
3.17.3
1 unspecified value
valid value of the relevant type where this International Standard imposes no
requirements on which value is chosen in any instance
2 NOTE An unspecified value cannot be a trap representation.
Add two more definitions to the main body of C1x:
3.17.4
1 trap representation
An object representation that need not represent a value of the object type.
3.17.5
1 to perform a trap
to interrupt execution of the program such that
no further operations are performed
2 NOTE
In this International Standard,
when the word "trap" is not immediately followed by "representation",
then this usage (3.17.5, "to perform a trap") is intended.
[Footnote: For example,
"Trapping or stopping (if supported) is disabled" (F.7.2 Translation).
Note that fetching a trap representation might, or might not, cause
trapping; see 6.2.6.1.]
[Note to WG14: 5.1.2.3 para 14 EXAMPLE 6 "On a machine in which overflows produce an explicit trap" could be re-written to "On a machine in which overflows perform a trap", and "the sum a + b would produce a trap" could be re-written to "the sum a + b would perform a trap".]
Because the other new material is proposed for an annex (such as Annex K), no other definition changes are proposed for the main body of C1x.
Add an informative annex to C1x for solutions to various C vulnerabilities (called "Annex K" in this paper), with a tentative title such as "Analyzability".
Provide the following definitions in Annex K:
N.1 to perform a trap
As defined at 3.17.5,
"to perform a trap" means
to interrupt execution of the program such that
no further operations are performed.
However, in this Annex K, this interruption
is permitted to take place by invoking a
runtime-constraint handler.
Any such semantics are implementation-defined.
N.2 out-of-bounds store
an (attempted) access (3.4.1) which, at run-time,
for a given computational state, would modify one or more
bytes (or for an object declared volatile, would fetch one or more bytes)
that lie outside the bounds permitted by the standard
N.3 bounded undefined behavior
behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard imposes
no requirements, except that the behavior shall not perform an
out-of-bounds store,
and that all values produced or stored are indeterminate values.
NOTE The behavior might perform a trap.
N.4 critical undefined behavior
behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard imposes
no requirements
NOTE the behavior might perform an out-of-bounds store,
or might perform a trap
All undefined behaviors defined in clauses 1 through 7 of this International Standard are (in this Annex K) restricted to the semantics of bounded undefined behavior, except for the following critical undefined behaviors:
| 6.2.4� | � An object is referred to outside of its lifetime |
| � 6.3.2.1 | � An lvalue does not designate an object when evaluated |
| � 6.5.3.2 | � The operand of the unary * operator has an invalid value |
| � 6.5.6 | � Addition or subtraction of a pointer into, or just beyond, an array object and an integer type produces a result that points just beyond the array object and is used as the operand of a unary * operator that is evaluated |
| � 7.20.3 | � The value of a pointer that refers to space deallocated by a call to the free or realloc function is used |
| 7.21.1, 7.24.4 � | � A string or wide string utility function is instructed to access an array beyond the end of an object |
Insert the contents of TR 24731-1 [BCL] into the new Annex K.