ISO/IEC JTC 1/SC 22/OWGV N0056

Various Versions of a Template for Language-Independent Descriptions of Vulnerabilities

13 December 2006

Compiled by Jim Moore

During and after meeting #3, OWGV and various members of OWGV, worked on a template for language-independent descriptions of vulnerabilities. This document captures some of the various versions.

Version 1

This is simply an example. It comes from [N0048]:

SM 004 Arrays Arrays consist of a set of storage for replicated data together with possibly a set of bounds for each dimension. The major issues for language systems for arrays are as follows: Static or dynamic bounds: In strongly typed systems, static bounds and invisibility of the explict storage make arrays secure. For strongly typed systems with dynamic bounds, the bounds are not directly accessible but attempts to exceed the bounds will result in exceptional processing. In weakly typed systems, arrays which should be statically bounded can often be cast to other forms of access, and access outside the bounds is also possible. Tooling or explicit runtime checks are required to ensure that this does not occur. In weakly typed systems, arrays which can be dynamically bounded will require explicit bounds to be maintained. These bounds can be changed by the application, resulting in inappropriate access to memory. For some language systems, the access to the storage region containing the object can be manipulated in ways other than access through the base object and an index. For HI systems, Tools and static analysis is required to show that this does not happen.

Version 2

This is a revised example done by Steve Michell following some initial discussion. It comes from [N0054]:

SM 004 Arrays Unpredictable behaviour can exist when accessing the elements of an array without first checking the bounds of the array and ensuring that the access is within the bounds. For statically defined arrays in language systems that enforce correct specification of the elemnts to be accessed this is provided by the language systems. For dynamicaly specified arrays in language systems that enforce legal access, out-of-bounds access can result in exceptional behaviour. For access in languages that do no no language-defined checks, out of range access can result in undefined behaviour and additional checks such as static analysis tools or human review is required. Another vulnerability can occur when other techniques such as direct pointers that rely upon knowledge of the representation provided by the implementation are used. Such techniques are problematic for tools and for human review and should be avoided.

Version 3

During the meeting, we considered Steve's revised version and performed some editing. The fields in [square brackets] are intended to describe the template.

[Identifier] SM 004 [Brief Title] Out of Bounds Array Element Access [What is the application vulnerability?] Unpredictable behaviour can occur when accessing the elements of an array outside the bounds of the array. [What are the possible ways to avoid the vulnerability?] The vulnerability can be avoided by not using arrays, by using whole array operations, by not attempting 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. [What is the mechanism of the failure? Or Why is this bad?] blah, blah, blah [Case analysis identifying the language vulnerability and its mitigation (including programmer action, tooling, other v&v).] For statically defined arrays in language systems that enforce correct specification of the elements to be accessed, this is typically provided by code generated by the compiler. The mitigation is for the programmer to define the array statically and to ensure that any variable used for indexing has the same bounds. For dynamically specified arrays in language systems that enforce legal access, out-of-bounds access can result in an exception. The programmer's responsibility is to catch the exception and treat it. Alternatively, the programmer might code explicit checks to ensure that no out-of-bounds access occurs. For access in languages that do no language-defined checks, out of range access can result in undefined behaviour and additional checks such as static analysis tools or human review is required. The programmer's responsibility is to code explicit checks to ensure that out of bounds access does not occur.

Version 4

After the meeting, Dan Nagle, Derek Jones, and Jim Moore produced this version. (Jim filled in some details afterward on his own.)

[Identifier] SM 004 [Brief Title] Out of Bounds Array Element Access [What is the application vulnerability?] Unpredictable behaviour can occur when accessing the elements of an array outside the bounds of the array. [What is the mechanism of the 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. [What are the 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. Assumed variations among languages: 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.) Avoiding the vulnerability or mitigating its effects: If possible utilize language features such as whole array operations that obviate the need to access individual elements. 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 (for example, a variable whose values are explicitly bounded by a type definition related to the array bounds); 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.