ISO/IEC TR 24772:2010

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

ISO/IEC TR 24772:2010 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.

Technologies de l'information — Langages de programmation — Conduite pour éviter les vulnérabilités dans les langages de programmation à travers la sélection et l'usage de la langue

General Information

• Status: Withdrawn
• Publication Date: 28-Sep-2010
• Withdrawal Date: 28-Sep-2010
• ICS: 35.060 - Languages used in information technology
• Technical Committee: ISO/IEC JTC 1/SC 22 - Programming languages, their environments and system software interfaces
• Drafting Committee: ISO/IEC JTC 1/SC 22 - Programming languages, their environments and system software interfaces
• Current Stage: 9599 - Withdrawal of International Standard
• Completion Date: 04-Mar-2013

Relations

• Revised: ISO/IEC TR 24772:2013 - Information technology — Programming languages — Guidance to avoiding vulnerabilities in programming languages through language selection and use
• Effective Date: 04-Feb-2012

Standards Content (Sample)

TECHNICAL ISO/IEC
REPORT TR
24772
First edition
2010-10-01


Information technology — Programming
languages — Guidance to avoiding
vulnerabilities in programming languages
through language selection and use
Technologies de l'information — Langages de programmation —
Conduite pour éviter les vulnérabilités dans les langages de
programmation à travers la sélection et l'usage de la langue




Reference number
ISO/IEC TR 24772:2010(E)
©
ISO/IEC 2010

---------------------- Page: 1 ----------------------
ISO/IEC TR 24772:2010(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


COPYRIGHT PROTECTED DOCUMENT


©  ISO/IEC 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland

ii © ISO/IEC 2010 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC TR 24772:2010(E)
Contents  Page
Foreword . vi
Introduction . vii
1  Scope . 1
2.  Normative references . 1
3  Terms and definitions, symbols and conventions . 1
3.1   Terms and definitions, symbols and conventions . 1
3.2  Symbols and conventions . 3
4.  Basic Concepts . 4
4.1  Not in Scope . 4
4.2   Approach . 4
4.3  Intended Audience . 4
4.4  How to Use This Document . 5
5  Vulnerability issues . 8
5.1   Issues arising from incomplete or evolving language specifications . 8
5.2   Issues arising from human cognitive limitations . 11
5.3   Issues arising from a lack of predictable execution . 12
5.4   Issues arising from the lack of portability and interoperability . 12
5.5   Issues arising from inadequate language intrinsic support . 13
5.6   Issues arising from language features prone to erroneous use . 13
6.  Programming Language Vulnerabilities . 14
6.1   General . 14
6.2   Obscure Language Features [BRS] . 14
6.3   Unspecified Behaviour [BQF] . 15
6.4   Undefined Behaviour [EWF] . 17
6.5   Implementation‐defined Behaviour [FAB] . 18
6.6   Deprecated Language Features [MEM] . 20
6.7   Pre‐processor Directives [NMP] . 21
6.8   Choice of Clear Names [NAI] . 23
6.9   Choice of Filenames and other External Identifiers [AJN] . 25
6.10  Unused Variable  [XYR] . 26
6.11  Identifier Name Reuse [YOW] . 27
6.12  Namespace Issues [BJL] . 30
6.13  Type System [IHN] . 31
6.14  Bit Representations [STR] . 34
6.15  Floating‐point Arithmetic [PLF] . 35
6.16  Enumerator Issues [CCB] . 38
6.17  Numeric Conversion Errors [FLC] . 40
© ISO/IEC 2010 – All rights reserved  iii

---------------------- Page: 3 ----------------------
ISO/IEC TR 24772:2010(E)
6.18  String Termination [CJM] . 42
6.19  Boundary Beginning Violation  [XYX] . 43
6.20  Unchecked Array Indexing  [XYZ] . 44
6.21  Unchecked Array Copying [XYW] . 46
6.22  Buffer Overflow [XZB] . 47
6.23  Pointer Casting and Pointer Type Changes [HFC] . 49
6.24  Pointer Arithmetic [RVG] . 50
6.25  Null Pointer Dereference [XYH] . 51
6.26  Dangling Reference to Heap [XYK] . 52
6.27  Templates and Generics [SYM] . 54
6.28  Inheritance [RIP] . 56
6.29  Initialization of Variables [LAV] . 57
6.30  Wrap‐around Error [XYY] . 59
6.31  Sign Extension Error [XZI] . 60
6.32  Operator Precedence/Order of Evaluation [JCW] . 61
6.33  Side‐effects and Order of Evaluation [SAM] . 63
6.34  Likely Incorrect Expression [KOA] . 64
6.35  Dead and Deactivated Code [XYQ] . 66
6.36  Switch Statements and Static Analysis [CLL] . 68
6.37  Demarcation of Control Flow [EOJ] . 69
6.38  Loop Control Variables [TEX] . 70
6.39  Off‐by‐one Error  [XZH] . 71
6.40  Structured Programming [EWD] . 73
6.41  Passing Parameters and Return Values [CSJ] . 74
6.42  Dangling References to Stack Frames  [DCM] . 77
6.43  Subprogram Signature Mismatch [OTR] . 79
6.44  Recursion [GDL] . 80
6.45  Returning Error Status [NZN] . 81
6.46  Termination Strategy [REU] . 84
6.47  Extra Intrinsics [LRM] . 85
6.48  Type‐breaking Reinterpretation of Data [AMV] . 87
6.49  Memory Leak [XYL] . 89
6.50  Argument Passing to Library Functions [TRJ] . 90
6.51  Dynamically‐linked Code and Self‐modifying Code [NYY] . 91
6.52  Library Signature [NSQ] . 92
6.53  Unanticipated Exceptions from Library Routines [HJW] . 93
7.  Application Vulnerabilities . 95
7.1  Adherence to Least Privilege  [XYN] . 95
7.2  Privilege Sandbox Issues [XYO] . 95
7.3  Executing or Loading Untrusted Code  [XYS] . 97
7.4  Unspecified Functionality  [BVQ] . 98
7.5   Distinguished Values in Data Types [KLK] . 99
7.6  Memory Locking  [XZX] . 100
iv  © ISO/IEC 2010 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC TR 24772:2010(E)
7.7   Resource Exhaustion [XZP] . 101
7.8  Injection [RST] . 102
7.9  Cross‐site Scripting  [XYT] . 105
7.10  Unquoted Search Path or Element  [XZQ] . 108
7.11  Improperly Verified Signature  [XZR] . 108
7.12  Discrepancy Information Leak  [XZL] . 109
7.13  Sensitive Information Uncleared Before Release [XZK] . 110
7.14  Path Traversal [EWR] . 111
7.15  Missing Required Cryptographic Step [XZS] . 113
7.16  Insufficiently Protected Credentials [XYM] . 113
7.17  Missing or Inconsistent Access Control [XZN] . 114
7.18  Authentication Logic Error [XZO] . 115
7.19  Hard‐coded Password [XYP] . 117
Annex A (informative) Guideline Selection Process . 118
A.1   Selection Process . 118
A.2   Cost/Benefit Analysis . 118
A.3   Documenting of the selection process . 119
Annex B (informative) Template for use in proposing programming language vulnerabilities . 120
B.1   6.  [] . 120
Annex C (informative) Template for use in proposing application vulnerabilities . 122
C.1   7.  [] . 122
Annex D (informative) Vulnerability Outline and List . 123
D.1   Vulnerability Outline . 123
D.2   Vulnerability List . 125
Annex E (informative) Language Specific Vulnerability Template . 127
E.1  .1 Identification of standards . 127
E.2  .2 General terminology and concepts . 127
E.3  .  [<3 letter tag>] . 127
Bibliography . 129


© ISO/IEC 2010 – All rights reserved  v

---------------------- Page: 5 ----------------------
ISO/IEC TR 24772:2010(E)
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.
ISO/IEC TR 24772 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 22, Programming languages, their environments and system software interfaces.
vi  © ISO/IEC 2010 – All rights reserved

---------------------- Page: 6 ----------------------
ISO/IEC TR 24772:2010(E)
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.
Furthermore, to focus its limited resources, the working group developing this report decided to defer
comprehensive treatment of several subject areas until future editions of the report. These subject areas
include:
 Object‐oriented language features (Although some simple issues related to inheritance are
described in RIP)
 Concurrency
 Numerical analysis (although some simple items regarding the use of floating point are described in
PLF)
 Scripting languages
 Inter‐language operability
 Language‐specific annexes

© ISO/IEC 2010 – All rights reserved  vii

---------------------- Page: 7 ----------------------
Technical Report  ISO/IEC TR 24772:2010(E)

Information technology — Programming languages —
Guidance to avoiding vulnerabilities in programming languages
through language selection and use
1  Scope
This Technical Report 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.
ISO/IEC 80000–2:2009, Quantities and units — Part 2: Mathematical signs and symbols to be use in the natural
sciences and technology
ISO/IEC 2382–1:1993, Information technology — Vocabulary — Part 1: Fundamental terms
3  Terms and definitions, symbols and conventions
3.1   Terms and definitions, symbols and conventions
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.
3.1.1
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
© ISO/IEC 2010 – All rights reserved  1

---------------------- Page: 8 ----------------------
ISO/IEC TR 24772:2010(E)
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.2
application vulnerability
security vulnerability or safety hazard, or defect
3.1.3
security vulnerability
weakness in an information system, system security procedures, internal controls, or implementation that could
be exploited or triggered by a threat
3.1.4
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”.
Note 2: IEC 61508 is titled “Functional safety of electrical/electronic/ programmable electronic safety‐related
systems”, with part 4 being “Definitions and abbreviations”.  Hence within IEC 61508 the “safety” context of
“safety hazard” is assumed.
Note 3: IEC 61508 cites ISO/IEC Guide 51 as the source for the definition.
Note 4: 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.5
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.
Note 2: 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.6
software quality
degree to which software implements the requirements described by its specification and the degree to which
the characteristics of a software product fulfil its requirements
2  © ISO/IEC 2010 – All rights reserved

---------------------- Page: 9 ----------------------
ISO/IEC TR 24772:2010(E)
3.1.7
predictable execution
property of the program such that all possible executions have results that can be predicted from the source code
Note 1: All the relevant language‐defined implementation characteristics and knowledge of the universe of
execution must be known.
Note 2: In some environments, this would raise issues regarding numerical stability, exceptional processing,
and concurrent execution.
Note 3: Predictable execution is an ideal that must be approached keeping in mind the limits of human
capability, knowledge, availability of tools, and other factors. Neither this Technical Report nor any standard
ensures predictable execution. Rather this Technical Report provides advice on improving predictability. The
purpose of this Technical Report is to assist a reasonably competent programmer to approach the ideal of
predictable execution.
Note 4: The following terms are used in relation to “Predictable execution”.
 Unspecified behaviour: A situation where the implementation of a language will have to make some
choice from a finite set of alternatives, but that choice is not in general predictable by the programmer,
for example, the order in which sub‐expressions are evaluated in an expression in many languages.
 Implementation‐defined behaviour: A situation where the implementation of a language will have to
make some choice, and it is required that this choice be documented and available to the programmer.
 Undefined behaviour: A situation where the definition of a language can give no indication of what
behaviour to expect from a program – it can be some form of catastrophic failure (a ‘crash’) or continued
execution with some arbitrary data.
Note 5: This Technical Report includes a clause on Unspecified functionality. This notion is related to neither
unspecified behaviour, which is a characteristic of an application, nor the language used to develop the
application.
3.2   Symbols and conventions
3.2.1  Symbols
For the purposes of this document, the symbols given in ISO/IEC 80000–2 apply.  Other symbols are defined
where they appear in this document.
3.2.2   Conventions
Programming language token and syntactic token appear in courier font.
© ISO/IEC 2010 – All rights reserved  3

---------------------- Page: 10 ----------------------
ISO/IEC TR 24772:2010(E)
4.  Basic Concepts
4.1  Not in Scope
This Technical Report does not address software engineering and management issues such as how to design and
implement programs, use configuration management tools, use managerial processes, and perform process
improvement.  Furthermore, the specification of properties to be assured is not treated.

The specification of an application is not within the scope.
While this Technical Report does not discuss specification or design issues, there is recognition that boundaries
among the various activities are not clear‐cut. This Technical Report seeks to avoid the debate about where low‐
level design ends and implementation begins by treating selected issues that some might consider design issues
rather than coding issues.
4.2  Approach
Guidelines based on this Technical Report are likely to be highly leveraged in that they are likely to affect many
times more people than the number that worked on them. Therefore guidelines such as
...