1、 ISO/IEC 2013 Information technology Programming languages, their environments and system software interfaces C secure coding rules Technologies de linformation Langages de programmation, leur environnement et interfaces des logiciels de systmes Rgles de programmation scurise en C ISO/IEC TS 17961 F
2、irst edition 2013-11-15 Reference number ISO/IEC TS 17961:2013(E) TECHNICAL SPECIFICATION ISO/IEC TS 17961:2013(E)ii ISO/IEC 2013 All rights reserved COPYRIGHT PROTECTED DOCUMENT ISO/IEC 2013 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized o
3、therwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below or ISOs member body in the country of the requester. ISO copyright off
4、ice Case postale 56 CH-1211 Geneva 20 Tel. + 41 22 749 01 11 Fax + 41 22 749 09 47 E-mail copyrightiso.org Web www.iso.org Published in Switzerland ISO/IEC TS 17961:2013(E) ISO/IEC 2013 All rights reserved iii Contents Page Foreword v Introduction vi 1 Scope . 1 2 Conformance . 1 2.1 Portability ass
5、umptions 2 3 Normative references 2 4 T erms and definitions . 2 5 Rules 5 5.1 Accessing an object through a pointer to an incompatible type ptrcomp . 5 5.2 Accessing freed memory accfree . 6 5.3 Accessing shared objects in signal handlers accsig . 7 5.4 No assignment in conditional expressions bool
6、asgn . 8 5.5 Calling functions in the C Standard Library other than abort, _Exit, and signal from within a signal handler asyncsig 9 5.6 Calling functions with incorrect arguments argcomp .11 5.7 Calling signal from interruptible signal handlers sigcall 12 5.8 Calling system syscall .13 5.9 Comparis
7、on of padding data padcomp .14 5.10 Converting a pointer to integer or integer to pointer intptrconv 14 5.11 Converting pointer values to more strictly aligned pointer types alignconv .15 5.12 Copying a FILE object filecpy 16 5.13 Declaring the same function or object in incompatible ways funcdecl .
8、16 5.14 Dereferencing an out-of-domain pointer nullref .18 5.15 Escaping of the address of an automatic object addrescape 18 5.16 Conversion of signed characters to wider integer types before a check for EOF signconv .19 5.17 Use of an implied default in a switch statement swtchdflt .19 5.18 Failing
9、 to close files or free dynamic memory when they are no longer needed fileclose .20 5.19 Failing to detect and handle standard library errors liberr 20 5.20 Forming invalid pointers by library function libptr .26 5.21 Allocating insufficient memory insufmem.28 5.22 Forming or using out-of-bounds poi
10、nters or array subscripts invptr .29 5.23 Freeing memory multiple times dblfree 34 5.24 Including tainted or out-of-domain input in a format string usrfmt.35 5.25 Incorrectly setting and using errno inverrno 37 5.26 Integer division errors diverr .39 5.27 Interleaving stream inputs and outputs witho
11、ut a flush or positioning call ioileave .40 5.28 Modifying string literals strmod .41 5.29 Modifying the string returned by getenv, localeconv, setlocale, and strerror libmod 42 5.30 Overflowing signed integers intoflow 43 5.31 Passing a non-null-terminated character sequence to a library function t
12、hat expects a string nonnullcs 44 5.32 Passing arguments to character-handling functions that are not representable as unsigned char chrsgnext .45 5.33 Passing pointers into the same object as arguments to different restrict-qualified parameters restrict 46 5.34 Reallocating or freeing memory that w
13、as not dynamically allocated xfree 47 5.35 Referencing uninitialized memory uninitref .48 5.36 Subtracting or comparing two pointers that do not refer to the same array ptrobj 49 5.37 Tainted strings are passed to a string copying function taintstrcpy .50 ISO/IEC TS 17961:2013(E)iv ISO/IEC 2013 All
14、rights reserved 5.38 Taking the size of a pointer to determine the size of the pointed-to type sizeofptr 50 5.39 Using a tainted value as an argument to an unprototyped function pointer taintnoproto .51 5.40 Using a tainted value to write to an object using a formatted input or output function taint
15、formatio .52 5.41 Using a value for fsetpos other than a value returned from fgetpos xfilepos .52 5.42 Using an object overwritten by getenv, localeconv, setlocale, and strerror libuse 53 5.43 Using character values that are indistinguishable from EOF chreof 54 5.44 Using identifiers that are reserv
16、ed for the implementation resident 55 5.45 Using invalid format strings invfmtstr 57 5.46 Tainted, potentially mutilated, or out-of-domain integer values are used in a restricted sink taintsink .58 Annex A (informative) Intra- to Interprocedural Transformations 59 Annex B (informative) Undefined Beh
17、a vior .63 Annex C (informative) Related Guidelines and References .71 Annex D (informative) Decidability of Rules .77 Bibliography .78 ISO/IEC TS 17961:2013(E) Foreword ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the speciali
18、zed 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 commi
19、ttees 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. Internationa
20、l 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. Pub
21、lication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. In other circumstances, particularly when there is an urgent market requirement for such documents, the joint technical committee may decide to publish an ISO/IEC Technical Specification (
22、ISO/IEC TS), which represents an agreement between the members of the joint technical committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting a vote. An ISO/IEC TS is reviewed after three years in order to decide whether it will be confirmed for a f
23、urther three years, revised to become an International Standard, or withdrawn. If the ISO/IEC TS is confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an International Standard or be withdrawn. Attention is drawn to the possibility that some
24、 of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights. ISO/IEC TS 17961 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 22, Programming languages, their e
25、nvironments and system software interfaces. ISO/IEC 2013 All rights reserved v ISO/IEC TS 17961:2013(E) Introduction Background An essential element of secure coding in the C programming language is a set of well-documented and enforceable coding rules. The rules specified in this Technical Specific
26、ation apply to analyzers, including static analysis tools and C language compiler vendors that wish to diagnose insecure code beyond the requirements of the language standard. All rules are meant to be enforceable by static analysis. The application of static analysis to security has been done in an
27、 ad hoc manner by different vendors, resulting in nonuniform coverage of significant security issues. This specification enumerates secure coding rules and requires analysis engines to diagnose violations of these rules as a matter of conformance to this specification. These rules may be extended in
28、 an implementation-dependent manner, which provides a minimum coverage guarantee to customers of any and all conforming static analysis implementations. The largest underserved market in security is ordinary, non-security-critical code. The security-critical nature of code depends on its purpose rat
29、her than its environment. The UNIX finger daemon (fingerd ) is an example of ordinary code, even though it may be deployed in a hostile environment. A user runs the client program, finger, which sends a user name to fingerd over the network, which then sends a reply indicating whether the user is lo
30、gged in and a few other pieces of information. The function of fingerd has nothing to do with security. However, in 1988, Robert Morris compromised fingerd by triggering a buffer overflow, allowing him to execute arbitrary code on the target machine. The Morris worm could have been prevented from us
31、ing fingerd as an attack vector by preventing buffer overflows, regardless of whether fingerd contained other types of bugs. By contrast, the function of /bin/login is purely related to security. A bug of any kind in /bin/login has the potential to allow access where it was not intended. This is sec
32、urity-critical code. Similarly, in safety-critical code, such as software that runs an X-ray machine, any bug at all could have serious consequences. In practice, then, security-critical and safety-critical code have the same requirements. There are already standards that address safety-critical cod
33、e and therefore security-critical code. The problem is that because they must focus on preventing essentially all bugs, they are required to be so strict that most people outside the safety-critical community do not want to use them. This leaves ordinary code like fingerd unprotected. This Technical
34、 Specification has two major subdivisions: preliminary elements (Clauses 14) and secure coding rules (Clause 5). Each secure coding rule in Clause 5 has a separate numbered subsection and a unique section identifier enclosed in brackets (for example, ptrcomp). The unique section identifiers are main
35、ly for use by other documents in identifying the rules should the section numbers change because of the addition or elimination of a rule. These identifiers may be used in diagnostics issued by conforming analyzers, but analyzers are not required to do so. Annexes provide additional information. Ann
36、ex C (informative) Related Guidelines and References identifies related guidelines and references per rule. A bibliography lists documents referred to during the preparation of this Technical Specification. The rules documented in this Technical Specification do not rely on source code annotations o
37、r assumptions of programmer intent. However, a conforming implementation may take advantage of annotations to inform the analyzer. The rules, as specified, are reasonably simple, although complications can exist in identifying exceptions. An analyzer that conforms to this Technical Specification sho
38、uld be able to analyze code without excessive false positives, even if the code was developed without the expectation that it would be analyzed. Many analyzers provide methods that eliminate the need to research each vi ISO/IEC 2013 All rights reserved ISO/IEC TS 17961:2013(E) diagnostic on every in
39、vocation of the analyzer. The implementation of such a mechanism is encouraged but not required. This Technical Specification assumes that an analyzers visibility extends beyond the boundaries of the current function or translation unit being analyzed (see Annex A (informative) Intra- to Interproced
40、ural Transformations). Completeness and soundness The rules specified in this Technical Specification are designed to provide a check against a set of programming flaws that are known from practical experience to have led to vulnerabilities. Although rule checking can be performed manually, with inc
41、reasing program complexity, it rapidly becomes infeasible. For this reason, the use of static analysis tools is recommended. It should be recognized that, in general, determining conformance to coding rules is computationally undecidable. The precision of static analysis has practical limitations. F
42、or example, the halting theorem of Computer Science states that there are programs whose exact control flow cannot be determined statically. Consequently, any property dependent on control flowsuch as haltingmay be indeterminate for some programs. A consequence of this undecidability is that it may
43、be impossible for any tool to determine statically whether a given rule is satisfied in specific circumstances. The widespread presence of such code may also lead to unexpected results from an analysis tool. Annex D (informative) Decidability of Rules provides information on the decidability of rule
44、s in this Technical Specification. However checking is performed, the analysis may generate false negatives: Failure to report a real flaw in the code is usually regarded as the most serious analysis error, as it may leave the user with a false sense of security. Most tools err on the side of cautio
45、n and consequently generate false positives. However, there may be cases where it is deemed better to report some high-risk flaws and miss others than to overwhelm the user with false positives. false positives: The tool reports a flaw when one does not exist. False positives may occur because the c
46、ode is sufficiently complex that the tool cannot perform a complete analysis. The use of features such as function pointers and libraries may make false positives more likely. To the greatest extent feasible, an analyzer should be both complete and sound with respect to enforceable rules. An analyze
47、r is considered sound with respect to a specific rule if it cannot give a false-negative result, meaning it finds all violations of a rule within the entire program. An analyzer is considered complete if it cannot issue false-positive results, or false alarms. The possibilities for a given rule are
48、outlined in Table 1. Table 1 Completeness and soundness False positives False negatives Y N N Sound with false positives Complete and sound Y Unsound with false positives Complete and unsound The degree to which conforming analyzers minimize false-positive diagnostics is a quality of implementation
49、issue. In other words, quantitative thresholds for false positives and false negatives are outside the scope of this Technical Specification. Security focus The purpose of this Technical Specification is to specify analyzable secure coding rules that can be automatically enforced to detect security flaws in C-conforming applications. To be considered a security flaw, a software bug must be triggerable by the actions of a malicious user or attacker.
