Baseline for Ed 2 of tr 24772

Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.

The main task of the joint technical committee is to prepare International Standards. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.

In exceptional circumstances, when the joint technical committee has collected data of a different kind from that which is normally published as an International Standard (“state of the art”, for example), it may decide to publish a Technical Report. A Technical Report is entirely informative in nature and shall be subject to review every five years in the same manner as an International Standard.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.

The committee responsible for this document is Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 22, Programming languages, their environments and system software interfaces.

This edition cancels and replaces ISO IEC TR 24772:2012. The main changes between this document and the previous version are:

• 
  Language-specific annexes (Annexes C through H) have been removed from the document and are being republished as language-specific parts, TR 24772-2 Programming Language Vulnerabilities – Specific guidance for Ada, TR 24772-3 Programming Language Vulnerabilities – Specific guidance for C, etc.
  
• 
  Vulnerabilities that were documented in clause 8 of version 2 are now documented as part of clauses 6 and 7.
  
• 
  New vulnerabilities are added.
  
• 
  Guidance material for each vulnerability given in subclause 6.X.5 is reworded to be more explicit and directive.
  
• 
  Addition material for some vulnerabilities has been added.
  

Introduction

All programming languages contain constructs that are incompletely specified, exhibit undefined behaviour, are implementation-dependent, or are difficult to use correctly. The use of those constructs may therefore give rise to vulnerabilities, as a result of which, software programs can execute differently than intended by the writer. In some cases, these vulnerabilities can compromise the safety of a system or be exploited by attackers to compromise the security or privacy of a system.

This Technical Report is intended to provide guidance spanning multiple programming languages, so that application developers will be better able to avoid the programming constructs that lead to vulnerabilities in software written in their chosen language and their attendant consequences. This guidance can also be used by developers to select source code evaluation tools that can discover and eliminate some constructs that could lead to vulnerabilities in their software or to select a programming language that avoids anticipated problems.

It should be noted that this Technical Report is inherently incomplete. It is not possible to provide a complete list of programming language vulnerabilities because new weaknesses are discovered continually. Any such report can only describe those that have been found, characterized, and determined to have sufficient probability and consequence.

Information Technology — Programming Languages — Guidance to avoiding vulnerabilities in programming languages through language selection and use

1. Scope

This document specifies software programming language vulnerabilities to be avoided in the development of systems where assured behaviour is required for security, safety, mission-critical and business-critical software. In general, this guidance is applicable to the software developed, reviewed, or maintained for any application.

Vulnerabilities are described in a generic manner that is applicable to a broad range of programming languages.

2. Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

IEC 60559:2011, Information technology -- Microprocessor Systems -- Floating-Point arithmetic

3. Terms and definitions, symbols and conventions

3.1 Terms and definitions

For the purposes of this document, the terms and definitions given in ISO/IEC 2382–1 and the following apply. Other terms are defined where they appear in italic type.

ISO and IEC maintain terminology databases for use in standardization are available at:

• 
  IEC Glossary, std.iec.ch/glossary
  
• 
  ISO Online Browsing Platform, www.iso.ch/obp/ui
  

3.1.1 Communication

3.1.1.1

protocol

set of rules and supporting structures for the interaction of threads

Note 1: A protocol can be tightly embedded and rely upon data in memory and hardware to control interaction of threads or can be applied to more loosely coupled arrangements, such as message communication spanning networks and computer systems.

3.1.1.2

stateless protocol

communication or cooperation between threads where no state is preserved in the protocol itself (example HTTP or direct access to a shared resource)

Note 1: Since most interaction between threads requires that state be preserved, the cooperating threads must use values of the resources(s) themselves or add additional communication exchanges to maintain state. Stateless protocols require that the application provide explicit resource protection and locking mechanisms to guarantee the correct creation, view, access to, modification of, and destruction of the resource – for example, the state needed for correct handling of the resource.

3.1.2 Execution model

3.1.2.1

thread

sequential stream of execution

Note 1: Although the term thread is used here and the context portrayed is that of shared-memory threads executing as part of a process, everything documented applies equally to other variants of concurrency such as interrupt handlers being enabled by a process, processes being created on the same system using operating system routines, or processes created as a result of distributed messages sent over a network. The mitigation approaches will be similar to those listed in the relevant vulnerability descriptions, but the implications for standardization would be dependent on how much language support is provided for the programming of the concurrent system.

3.1.2.2

thread activation

creation and setup of a thread up to the point where the thread begins execution

Note 1: A thread may depend upon one or more other threads to define its access to other objects to be accessed and to determine its duration.

3.1.2.3

activated thread

thread that is created and then begins execution as a result of thread activation

3.1.2.4

activating thread

thread that exists first and makes the library calls or contains the language syntax that causes the activated thread to be activated

Note 1: The activating thread may or may not wait for the activated thread to finish activation and may or may not check for errors if the activation fails. The activating thread may or may not be permitted to terminate until after the activated thread terminates.

3.1.2.5

static thread activation

creation and initiation of a thread by program initiation, an operating system or runtime kernel, or by another thread as part of a declarative part of the thread before it begins execution

Note 1: In static activation, a static analysis can determine exactly how many threads will be created and how much resource, in terms of memory, processors, CPU cycles, priority ranges and inter-thread communication structures, will be needed by the executing program before the program begins.

3.1.2.6

dynamic thread activation

creation and initiation of a thread by another thread (including the main program) as an executable, repeatable command, statement or subprogram call

3.1.2.7

thread abort

request to stop and shut down a thread immediately

Note 1: The request is asynchronous if from another thread, or synchronous if from the thread itself. The effect of the abort request (such as whether it is treated as an exception) and its immediacy (that is, how long the thread may continue to execute before it is shut down) depend on language-specific rules. Immediate shutdown minimizes latency but may leave shared data structures in a corrupted state.

3.1.2.8

termination-directing thread

thread (including the OS) that requests the abortion of one or more threads

3.1.2.9

thread termination

completion and orderly shutdown of a thread, where the thread is permitted to make data objects consistent, release any acquired resources, and notify any dependent threads that it is terminating

Note 1: There are a number of steps in the termination of a thread as listed below, but depending upon the multithreading model, some of these steps may be combined, may be explicitly programmed, or may be missing:

• 
  the termination of programmed execution of the thread, including termination of any synchronous communication;
  
• 
  the finalization of the local objects of the thread;
  
• 
  waiting for any threads that may depend on the thread to terminate;
  
• 
  finalization of any state associated with dependent threads;
  
• 
  notification that finalization is complete, including possible notification of the activating task;
  
• 
  removal and cleanup of thread control blocks and any state accessible by the thread or by other threads in outer scopes.
  

3.1.2.10

terminated thread

thread that has been halted from any further execution

3.1.2.11

master thread

thread which must wait for a terminated thread before it can take further execution steps (including termination of itself)

3.1.2.12

process

single execution of a program, or portion of an application

Note 1: Processes do not normally share a common memory space, but often share

• 
  processor,
  
• 
  network,
  
• 
  operating system,
  
• 
  filing system,
  
• 
  environment variables, or
  
• 
  other resources.
  

Processes are usually started and stopped by an operating system and may or may not interact with other processes. A process may contain multiple threads.

3.1.3 Properties

3.1.3.1

software quality

degree to which software implements the requirements described by its specification and the degree to which the characteristics of a software product fulfill its requirements

3.1.3.2

predictable execution

property of the program such that all possible executions have results that can be predicted from the source code

3.1.4 Safety

3.1.4.1

safety hazard

potential source of harm

Note 1: IEC 61508–4: defines a “Hazard” as a “potential source of harm”, where “harm” is “physical injury or damage to the health of people either directly or indirectly as a result of damage to property or to the environment”. Some derived standards, such as UK Defence Standard 00-56, broaden the definition of “harm” to include material and environmental damage (not just harm to people caused by property and environmental damage).

3.1.4.2

safety-critical software

software for applications where failure can cause very serious consequences such as human injury or death

Note 1: IEC 61508–4: defines “Safety-related software” as “software that is used to implement safety functions in a safety-related system. Notwithstanding that in some domains a distinction is made between safety-related (can lead to any harm) and safety-critical (life threatening), this Technical Report uses the term safety-critical for all vulnerabilities that can result in safety hazards.

3.1.5 Vulnerabilities

3.1.5.1

application vulnerability

security vulnerability or safety hazard, or defect

3.1.5.2

language vulnerability

property (of a programming language) that can contribute to, or that is strongly correlated with, application vulnerabilities in programs written in that language

Note 1: The term "property" can mean the presence or the absence of a specific feature, used singly or in combination. As an example of the absence of a feature, encapsulation (control of where names can be referenced from) is generally considered beneficial since it narrows the interface between modules and can help prevent data corruption. The absence of encapsulation from a programming language can thus be regarded as a vulnerability. Note that a property together with its complement can both be considered language vulnerabilities. For example, automatic storage reclamation (garbage collection) can be a vulnerability since it can interfere with time predictability and result in a safety hazard. On the other hand, the absence of automatic storage reclamation can also be a vulnerability since programmers can mistakenly free storage prematurely, resulting in dangling references.

3.1.5.3

security vulnerability

weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat