ISO/IEC JTC 1/SC 22/OWGV N0072

Template for Language-Independent Descriptions of Vulnerabilities

Version 5

Edited by Jim Moore, 5 May 2007

This version was created based on Version 4 of the template contained in N0056. It contains changes decided at Meeting #4 of OWGV.

Worked example of a template

8.x SM-004 Out of bounds array element access 8.x.1 Description of application vulnerability Unpredictable behaviour can occur when accessing the elements of an array outside the bounds of the array. 8.x.2 Cross reference CWE: 129 8.x.3 Categorization See clause 5.?. 8.x.4 Mechanism of failure Arrays are defined, perhaps statically, perhaps dynamically, to have given bounds. In order to access an element of the array, index values for one or more dimensions of the array must be computed. If the index values does not fall within the defined bounds of the array, then access might occur to the wrong element of the array, or access might occur to storage that is outside the array. A write to a location outside the array may change the value of other data variables or may even change program code. 8.x.5 Possible ways to avoid the vulnerability The vulnerability can be avoided by not using arrays, by using whole array operations, by checking and preventing access beyond the bounds of the array, or by catching erroneous accesses when they occur. The compiler might generate appropriate code, the run-time system might perform checking, or the programmer might explicitly code appropriate checks. 8.x.6 Assumed variations among languages This vulnerability description is intended to be applicable to languages with the following characteristics: The size and bounds of arrays and their extents might be statically determinable or dynamic. Some languages provide both capabilities. Language implementations might or might not statically detect out of bound access and generate a compile-time diagnostic. At run-time the implementation might or might not detect the out of bounds access and provide a notification at run-time. The notification might be treatable by the program or it might not be. Accesses might violate the bounds of the entire array or violate the bounds of a particular extent. It is possible that the former is checked and detected by the implementation while the latter is not. The information needed to detect the violation might or might not be available depending on the context of use. (For example, passing an array to a subroutine via a pointer might deprive the subroutine of information regarding the size of the array.) Some languages provide for whole array operations that may obviate the need to access individual elements. Some languages may automatically extend the bounds of an array to accommodate accesses that might otherwise have been beyond the bounds. (This may or may not match the programmer's intent.) 8.x.7 Avoiding the vulnerability or mitigating its effects Software developers can avoid the vulnerability or mitigate its ill effects in the following ways: If possible, utilize language features for whole array operations that obviate the need to access individual elements. If possible, utilize language features for matching the range of the index variable to the dimension of the array. If the compiler can verify correct usage, then no mitigation is required beyond performing the verification. If the run-time system can check the validity of the access, then appropriate action may depend upon the usage of the system (e.g. continuing degraded operation in a safety-critical system versus immediate termination of a secure system). Otherwise, it is the responsibility of the programmer: to use index variables that can be shown to be constrained within the extent of the array; to explicitly check the values of indexes to ensure that they fall within the bounds of the corresponding dimension of the array; to use library routines that obviate the need to access individual elements; or to provide some other means of assurance that arrays will not be accessed beyond their bounds. Those other means of assurance might include proofs of correctness, analysis with tools, verification techniques, etc.

Skeleton template for use in proposing vulnerabilities

8.<x> <unique immutable identifier> <short title> <Notes on template header. The number "x" depends on the order in which the vulnerabilities are listed in Clause 8. It will be assigned by the editor. The "unique immutable identifier" is intended to provide an enduring identifier for the vulnerability description, even if their order is changed in the document. The "short title" should be a noun phrase summarizing the description of the application vulnerability. No additional text should appear here.> 8.<x>.1 Description of application vulnerability <Replace this with a brief description of the application vulnerability. It should be a short paragraph.> 8.<x>.2 Cross reference CWE: <Replace this with the CWE identifier. At a later date, other cross-references may be added.> 8.<x>.3 Categorization See clause 5.?. <Replace this with the categorization according to the analysis in Clause 5. At a later date, other categorization schemes may be added.> 8.<x>.4 Mechanism of failure <Replace this with a brief description of the mechanism of failure. This description provides the link between the programming language vulnerability and the application vulnerability. It should be a short paragraph.> 8.<x>.5 Possible ways to avoid the vulnerability <Replace this with a description of the various points at which the chain of causation could be broken. It should be a short paragraph.> 8.<x>.6 Assumed variations among languages This vulnerability description is intended to be applicable to languages with the following characteristics: <Replace this with a bullet list summarizing the pertinent range of characteristics of languages for which this discussion is applicable. This list is intended to assist readers attempting to apply the guidance to languages that have not been treated in the language-specific annexes.> 8.<x>.7 Avoiding the vulnerability or mitigating its effects Software developers can avoid the vulnerability or mitigate its ill effects in the following ways: <Replace this with a bullet list summarizing various ways in which programmers can avoid the vulnerability or contain its bad effects. Begin with the more direct, concrete, and effective means and then progress to the more indirect, abstract, and probabilistic means.