Baseline for Ed 2 of tr 24772

5 Vulnerability issues and general avoidance mechanisms

5.1 Predictable execution

There are many reasons why software might not execute as expected by its developers, its users or other stakeholders. Reasons include incorrect specifications, configuration management errors and a myriad of others. This Technical Report focuses on one cause—the usage of programming languages in ways that render the execution of the code less predictable.

Predictable execution is a property of a program such that all possible executions have results that can be predicted from examination of the source code. Achieving predictability is complicated by that fact that software may be used:

• 
  on unanticipated platforms (for example, ported to a different processor)
  
• 
  in unanticipated ways (as usage patterns change),
  
• 
  in unanticipated contexts (for example, software reuse and system-of-system integrations), and
  
• 
  by unanticipated users (for example, those seeking to exploit and penetrate a software system).
  

Furthermore, today’s ubiquitous connectivity of software systems virtually guarantees that most software will be attacked—either because it is a target for penetration or because it offers a springboard for penetration of other software. Accordingly, today’s programmers must take additional care to ensure predictable execution despite the new challenges.

Software vulnerabilities are unwanted characteristics of software that may allow software to execute in ways that are unexpected. Programmers introduce vulnerabilities into software by using language features that are inherently unpredictable in the variable circumstances outlined above or by using features in a manner that reduces what predictability they could offer. Of course, complete predictability is an ideal (particularly because new vulnerabilities are often discovered through experience), but any programmer can improve predictability by carefully avoiding the introduction of known vulnerabilities into code.

This Technical Report focuses on a particular class of vulnerabilities, language vulnerabilities. These are properties of programming languages that can contribute to (or are strongly correlated with) application vulnerabilities—security weaknesses, safety hazards, or defects. An example may clarify the relationship. The programmer’s use of a string copying function that does not check length may be exploited by an attacker to place incorrect return values on the program stack, hence passing control of the execution to code provided by the attacker. The string copying function is the language vulnerability and the resulting weakness of the program in the face of the stack attack is the application vulnerability. The programming language vulnerability enables the application vulnerability. The language vulnerability can be avoided by using a string copying function that does set appropriate bounds on the length of the string to be copied. By using a bounded copy function the programmer improves the predictability of the code’s execution.

The primary purpose of this Technical Report is to survey common programming language vulnerabilities; this is done in Clause 6. Each description explains how an application vulnerability can result. In Clause 7, a few additional application vulnerabilities are described. These are selected because they are associated with language weaknesses even if they do not directly result from language vulnerabilities. For example, a programmer might have stored a password in plain text (see Error: Reference source not found) because the programming language did not provide a suitable library function for storing the password in a non-recoverable format.

In addition to considering the individual vulnerabilities, it is instructive to consider the sources of uncertainty that can decrease the predictability of software. These sources are briefly considered in the remainder of this clause.

5.2 Sources of unpredictability in language specification

5.2.1 Incomplete or evolving specification

The design and specification of a programming language involves considerations that are very different from the use of the language in programming. Language specifiers often need to maintain compatibility with older versions of the language—even to the extent of retaining inherently vulnerable features. Sometimes the semantics of new or complex features aren’t completely known, especially when used in combination with other features.

5.2.2 Undefined behaviour

It’s simply not possible for the specifier of a programming language to describe every possible behaviour. For example, the result of using a variable to which no value has been assigned is left undefined by many languages. In such cases, a program might do anything—including crashing with no diagnostic or executing with wrong data, leading to incorrect results.

5.2.3 Unspecified behaviour

The behaviour of some features may be incompletely defined. The language implementer would have to choose from a finite set of choices, but the choice may not be apparent to the programmer. In such cases, different compilers may lead to different results.

5.2.4 Implementation-defined behaviour

In some cases, the results of execution may depend upon characteristics of the compiler that was used, the processor upon which the software is executed, or the other systems with which the software has interfaces. In principle, one could predict the execution with sufficient knowledge of the implementation, but such knowledge is sometimes difficult to obtain. Furthermore, dependence on a specific implementation-defined behaviour will lead to problems when a different processor or compiler is used—sometimes if different compiler switch settings are used.

5.2.5 Difficult features

Some language features may be difficult to understand or to use appropriately, either due to complicated semantics (for example, floating point in numerical analysis applications) or human limitations (for example, deeply nested program constructs or expressions). Sometimes simple typing errors can lead to major changes in behaviour without a diagnostic (for example, typing “=” for assignment when one really intended “==” for comparison).