ISO/IEC JTC 1/SC 22/OWGV N 0089

Approved Minutes
Meeting #5 of ISO/JTC1/SC22/OWG: Vulnerability
18 - 20 July 2007, Ottawa, Canada

These minutes were approved at Meeting #6.

Meeting Information

Meeting Times:

18 July 2007 09:00-12:00 13:30-17:00
19 July 2007 09:00-12:00 13:30-17:00
20 July 2007 09:00-12:00

Meeting Location:

Standards Council of Canada
2nd Floor, 270 Albert St.
Ottawa, Ontario
Canada

Meeting Information:

Logistics information for meeting #5 [N0076]

Host:

Standards Council of Canada
Canada

Host Contact information:

Email: Stephen Michell

These minutes are organized by agenda items, regardless of the temporal order of discussion.

Agenda

1. Opening activities

1.1 Opening Comments (Michell, Benito)

Steve Michell welcomes us to the Standards Council of Canada (SCC) and to Ottawa and explains the administrative arrangements for the meeting.

1.2 Introduction of Participants/Roll Call

The participants introduce themselves:

1.3 Procedures for this Meeting (Benito)

John briefly reviews appropriate rules of etiquette for the meeting.

1.4 Approval of previous Minutes, [N0069] (Moore)

The minutes are approved.

1.5 Review of previous actions items and resolutions, Action Item and Decision Logs

John and Jim had updated the logs just before the meeting. Additional items are updated at the meeting.

1.6 Approval of Agenda [N0080]

Items marked as "[Added]" in sections 3 and 4 of these minutes are added to the agenda. The agenda is approved as amended.

1.7 Information on Future Meetings.

1.7.1 Future Meeting Schedule
1.7.2 Future Agenda Items
1.7.3 Future Mailings

2. Reports on Liaison Activities

2.1 SC 22, Response to ISO/IEC JTC 1/SC 27 [N0075]

The referenced document is the liaison report that Jim produced at the direction of Meeting #4. Because of the scheduling of meetings, WG4 probably has not yet seen this report.

2.2 J3/WG5 (Fortran)

Dan reports that they will nail down the final contents of Fortran 2008 at their next meeting, which will occur within a few weeks. They will ballot the CD in 2008, and plan to publish in 2009. However, that revision will probably be a minor revision that will not deal with vulnerabilities. Treatment of vulnerabilities would be appropriate for a subsequent TR or possibly for the following revision.

2.3 J4/WG4 (COBOL)

No report.

2.4 WG9 (Ada)

Steve Michell reports that WG9 remains interested, but believes that they have probably dealt with the problems that OWGV may find. WG9 will need to revise their TR 15942 because the Ada language has been amended.

2.5 J11/WG14 (C)

WG14 has not yet had a meeting since OWGV meeting #4. The group will be planning a revision to the C language. There is a possibility of subsetting the language, particularly in the area of floating point.

2.6 ECMA TC39/TG2 (C#)

No report.

2.7 MISRA (C)

No report.

2.8 MISRA (C++)

Derek reports that there is a document ready for review. It is unlikely that the document has been reviewed by the C++ working group of SC22. Derek provides the following excerpt from the latest MISRA newsletter. It contains information advising how to get on the review list for the document.

 MISRA has been developing a set of guidelines for the use of the C++ language in critical systems. The aim of the guidelines is to provide a set of rules, in a similar fashion to the MISRA C rules, which encourage good programming practices and avoid poorly-defined or insecure features of the language.

MISRA is pleased to announce that a draft of MISRA C++ is now available for public comment.

To participate in the review, please download a reply form from the MISRA website and return it by fax or post to MIRA [sic] at the address shown at the top of the form. As this form requires a signature to indicate acceptance of the terms of the review, only fully completed and signed copies can be accepted.

We will then send you the draft and the details of the review process.

The review reply form can be found at
http://www.misra.org.uk/misra_cpp_eoi.pdf

2.9 SPARK

No report

2.10 MDC (MUMPS)

No report

2.11 SC7/WG19 (UML)

No report

2.12 Other Liaison Activities or National body reports

2.12.1 [Added] Liaison Report: JSR-282 (Real-Time Specification for Java) and JSR-302 (Safety-Critical Java Technologies), Ben Brosgol [N0088]

(This report was reviewed by the respective chairs of the two JSRs prior to submission to OWGV.) The report analyzes Java for the characteristics of predictability, reliability, and analyzability and describes the process for incorporating JSRs into the language. Finally, it describes the work of the two JSRs.

3. Document Review

3.1 [Replaced with 3.6] (Revised) "Proposal to the ISO/IEC Project 22.24772: Guidance for Avoiding Vulnerabilities through Language Selection and Use" [N0073] and directory of proposed vulnerability descriptions [dir, zip], personal contribution by Larry Wagoner, 21 June 2007.

3.2 (Revised) "Forms of language specification: Examples from commonly used computer languages" [N0078] and directory of proposed vulnerability descriptions [dir, zip], personal contribution from Derek M. Jones.

This is a revision of a document previously submitted. It describes how different language describe unspecified and implementation dependent features. Because of the differing terminology used in various programming language standards, it helps us to understand the respective standards and understand the terminology that they use. Ben Brosgol, referring to Table .1 says that the "No" for Java should be changed to "Yes". This document might be used in a rationale for the TR or referenced in the bibliography of the TR. Jim suggests, and it is agreed, that the document might be revised to be more of a manual, answering questions for each language like the following: where is the language specified; where is the library specified; how does the standard describe implementation-defined behavior; etc. This is entered in the Decision Log as item #05-01 and in the Action Item Log as #05-01.

Three of Derek's four proposed vulnerabilities are "catch-alls" describing classes of vulnerabilities based on the analysis in [N0078]. They should be added to the set of vulnerabilities. From time to time, we may find specific instances of them; they should also be added to the list as discovered. This is entered in the Decision Log as item #05-02.

3.3 Working Draft #4 (2007-06-29) of PDTR 24772 [N0079]

The change bars represent changes since Meeting #4 in Padua. They will be removed immediately after this meeting and the result placed on the Wiki as the basis for the next version.

3.4 [Added] James W. Moore and Robert Seacord, "Secure Coding becomes Standard," [N0082] presentation to Systems and Software Technology Conference (SSTC), June 19, 2007.

No need for further review.

3.5 [Added] Comments on “Software for Dependable Systems”, contribution by Tom Plum [N0083]

This concerns a report from the National Academy of Sciences. Tom contribution summarizes their preliminary report. Apparently, the report is now finished and there will be no follow-on process.

3.6 [Added] (2nd Revision) "Proposal to the ISO/IEC Project 22.24772: Guidance for Avoiding Vulnerabilities through Language Selection and Use" [N0084]; directory of proposed vulnerability descriptions [dir, zip]; and cover note [pdf] -- personal contribution by Larry Wagoner, 11 July 2007

This is a revision of the previously submitted documents. It describes his analysis of the vulnerabilities that should be considered for the technical report.

3.7 [Added] "Definition of Vulnerability" [N0085], contribution by Ben Brosgol, 12 July 2007.

We consider this proposal and formulate a revised set of definitions as document [N0091]. Benito is given Action Item #05-02 to incorporate the definitions in the next revision of the TR.

3.8 [Added] "The Physics of a Vulnerability," [N0086] by Bob Martin. Contributed by Jim Moore with the permission of The MITRE Corporation.

This is discussed subsequently as 4.3.5.1.

3.9 [Added] "Possible text for sub-clause 1.4" [N0087], contributed by Jim Moore.

This is discussed subsequently as 4.3.2.

4. Other Business

4.1 [Added] Reconsider Decision Log Item #02-02: "We will ask the language committees for a list of all "processor-dependent" or "implementation-dependent" features of their languages."

Some language standards, e.g. C and Fortran, have provided annexes that summarize this information. There is a helpful annex in Ada for some information and other relevant information is annotated throughout the text.

Jim suggests that we close this decision item in the log and replace it with an action item for Derek: "In the revision of N0078, describe how this information can be found in the various language specifications." This is added to the Action Item log as item #05-03.

4.2 [Added] Should there be a published Rationale for the TR?

For now, no one has volunteered to write a rationale. Furthermore, it appears that there will be sufficient data in the TR itself. The addition of a new clause covering non-language vulnerabilities might remove the need for a rationale covering rejected templates. Further discussion is deferred to the next meeting. John Benito is given Action Item #05-04 to table this item at the next meeting.

4.3 [Added] Discussion of TR:

4.3.1 Review the current draft TR [N0079]

We quickly walk through the draft TR, then return to the specific topics listed in subsequent agenda items.

4.3.2 Consider the proposal for subclause 1.4 [N0087]

Re subclause 1.4, Ben wonders if "predictability" is really a distinct community. We revise subclause 1.4, resulting in [N0090]. John is given Action Item #05-05 to incorporate this into the next revision of the draft TR.

4.3.3 Consider Derek Jones's proposed vulnerabilities [N0078-annex]

The issue arises of how to manage drafts of these vulnerabilities. The suggestion is that we create a directory of directories. The first time that a vulnerability is discussed, we will assign its immutable identifier-a three-character string of arbitrary alphabetic characters. Each identifier corresponds to a directory. Successive versions of the description will be added to the appropriate directory and will have increasing dates added to the filename. Appending a descriptive name is permitted. For example, the filename of a vulnerability might be:
BQF070718-unspecified-behavior.doc.

We decide to maintain these as DOC files rather than HTML. We will use change marking when appropriate and will try not to use features or formats more recent than Word 2003.

The directory name would also include the status of the proposal (IN, OUT or PENDING) and the descriptive name, e.g. BQF-IN-unspecified behavior.

When one combines or splits existing vulnerability descriptions, the new ones should be assigned new unique identifiers. The history section should explain the origin of the new description.

The TR as it evolves will list the set of vulnerabilities and whether they are currently regarded as included in the document or excluded from the document.

We annotate the submitted vulnerability descriptions with suggestions for improvement. The results are included in [N0093] as BQF, EWF, FAB, and YOW. All are considered as PENDING because substantial rewriting is required.

Derek takes Action Item #05-11 to revise the descriptions and resubmit them.

4.3.4 Consider Larry Wagoner's proposed vulnerabilities [N0084-annex]

In order to fit into the newly decided identification scheme for vulnerability descriptions, Larry's proposals are renamed according to the following scheme:

Ben suggests some groupings:

We decide to consider the vulnerabilities using this grouping. Eventually, we decide that all of the descriptions in some of the groups should be combined into a single description. In other cases, we decide to add the group name to the categorization of subclause 6.3.

We consider the descriptions related to dynamic allocation and annotate them with suggestions for improvement. They are included in [N0093] as distinct descriptions (XYH, XYK, XYL) but "Dynamic Allocation" is added to their categorization.

We consider the descriptions related to arithmetic and annotate them with suggestions for improvement. Various suggestions for combining them are offered. For now, they are included in [N0093] as distinct descriptions (XYE, XYF, XYY, XZI) but "Arithmetic" is added to their categorization.

Tom Plum takes Action Item #05-13 to provided words regarding "RSIZE_T" and "verifiably representable" for XYE.

We consider the descriptions related to array bounds and annotate them with suggestions for improvement. Various suggestions for combining them are offered. For now, they are included in [N0093] as distinct descriptions (XYW, XYX, XYZ, XZB) but "Array Bounds" is added to their categorization.

Tom takes Action Item #05-06: Ask CWE to change the names of "Stack Overflow" and "Heap Overflow" to "Buffer Overflow in Stack" and "Buffer Overflow in Heap". Also ask them to change "Process Control" to "Executing or Loading Untrusted Code".

We consider the descriptions related to concurrency. We reaffirm a past decision to set aside items related to concurrency. For now, they are included in [N0093] as distinct descriptions (XYI, XYJ, XZA) but "Concurrency" is added to their categorization. Their status is shown as OUT.

With respect to XYI, John Benito takes Action Item #05-14 to investigate CWE 365 to determine what is intended.

We consider the descriptions related to other language issues and annotate them with suggestions for improvement. Various suggestions for combining them are offered. For now they are included in [N0093] as distinct descriptions (XYQ, XYR, XZH, XZM, XYG).

For XYQ, Ben was asked to draft a paragraph regarding the distinction between dead and deactivated code. He provided these definitions from DO-178B:

Dead code - Executable object code (or data) which, as a result of a design error cannot be executed (code) or used (data) in an operational configuration of the target computer environment and is not traceable to a system or software requirement. An exception is embedded identifiers.

Deactivated code - Executable object code (or data) which by design is either (a) not intended to be executed (code) or used (data), for example, a part of a previously developed software component, or (b) is only executed (code) or used (data) in certain configurations of the target computer environment, for example, code that is enabled by a hardware pin selection or software programmed options.

We then go on to consider the remaining vulnerability descriptions proposed by Larry. The results are included in [N0093].

He was requested to combine XYA, XYB, XYC, and XYD into a single proposal (EWR) concerning path traversal.

Some of the proposals (XYM, XYN, XYO, XYP) are considered to be application security problems. It is decided to place them into a separate clause of the TR, tentatively numbered as Clause 7. We should mine them for proposals to be made to the language WGs and API WGs for improved library capabilities.

Proposals XYS and XYT are also considered to be application security issues and candidates for Clause 7.

Several proposals (XYU, XYV, XZC, XZD, XZE, XZF, XZG, XZJ) are considered to be types of injection vulnerabilities. They should be combined into a single proposal (RST).

XZK, XZS and XZX are considered to be examples where we would ask for an API to be changed.

XZR was determined to be the result of mistakes in cutting and pasting. It needs to be rewritten.

The remaining items (XZL, XZN, XZO, XZP, XZQ) are considered to be examples of application vulnerabilities and are candidates for a distinct clause 7.

Tom takes Action Item #05-16 to contact ECMA TC39/TG1 re ECMAscript security.

The results of the discussion are included in [N0093]. Most of the descriptions are considered as PENDING because substantial rewriting is required; the ones related to concurrency are considered as OUT for now.

Larry takes Action Item #05-10 to revise the descriptions and resubmit them.

Steve takes Action Item #05-12 to review safety documents (61508, DO178B, others), to look for safety hazards that we should treat in the TR.

4.3.5 Reconsider the format of the template based on experience to date [N0072]
4.3.5.1 Consider Jim Moore's chart on "Physics of Vulnerability" [N0086]

We decide to add a "History" section for tracking our own revisions. We will add a section for citing references. It will be used and referenced in a form permitting the items to be moved into a Bibliography. Add a "Status" section at the top to record in, out, tentative, etc. Leave the categorization section as is but add Ben's suggestions of groupings. Make it clear that cross-reference to CWE is not unique; other cross-referencing may be added. Reconsider whether classification based on Clause 5 is useful. Merge the .5 section with the .7 section; that section should go after "assumed variations". Change .6 to "Range of language characteristics considered". Add a section with recommendations for PL and API standardizers-- "Implications for standardization".

We decide to add a Clause 7 for vulnerabilities that appear to be at the application level rather than PL vulnerabilities with a modified template--dropping the section on "variations among programming languages"

Jim takes Action Item #05-15: Contact SC 27/WG 4 and suggest that an appropriate interface between their work and our work is for them to suggest capabilities that should be included in programming languages, language libraries, and APIs for use by those performing application security.

Jim implements the suggested changes as a new version of the template, [N0092].

4.3.6 Review the current draft TR (encore) [N0079]

It is suggested that Clause 5 should discuss forbidding unanticipated behaviour as well as implementing expected behaviour. Ben or Dan may provide proposals for changes in this regard.

John asks that participants might suggest additional references to be placed in the Bibliography of the TR. John plans to add TR 24731, the new C bounded library functions. These are added as Action Items #05-07 and #05-08.

John plans to request that registration of the draft TR be performed at the SC22 plenary. He takes Action Item #05-09 to submit a draft of the TR prior to the 7 August document submission deadline.

He mentioned that it is important for participants from various nations to ask their respective national bodies to support registration at the plenary meeting.

5. Resolutions

5.1 Review of Decisions Reached

The following decisions are to be added to the Decision Log:

#05-01: A successor to N0078 might be used in a rationale for the TR or referenced in the bibliography of the TR. The document should be revised to be more of a manual, answering questions for each language like the following: where is the language specified; where is the library specified; how does the standard describe implementation-defined behavior; etc.
#05-02: As specific examples of the catch-all vulnerabilities are discovered, they should be added to the set as distinct vulnerabilities.

5.2 Formal Votes on Resolutions

There are no resolutions.

5.3 Review of Action Items

The following action items are to be added to the Action Item Log:

#05-01: Jones: Revise N0078 in accordance with Decision Log Item #05-01, and in Table .1, change the "No" for Java to "yes".
#05-02: Benito: Incorporate N0091 in the next version of the TR.
#05-03: Jones: Revise N0078 to describe how "processor-dependent" or "implementation-dependent" features of various programming languages can be located in their respective standards.
#05-04: Benito: For meeting #6, table the question of whether there should be a rationale document.
#05-05: Benito: Incorporate N0090 in the next version of the TR.
#05-06: Plum: Ask CWE to change the names of "Stack Overflow" and "Heap Overflow" to "Buffer Overflow in Stack" and "Buffer Overflow in Heap". Also ask them to change "Process Control" to "Executing or Loading Untrusted Code".
#05-07: All: Recommend additional items for the Bibliography of the TR
#05-08: Benito: Add TR 24731 to the Bibliography of the draft TR.
#05-09: Benito: Submit the draft of the TR to SC22 by the time of the deadline permitting it to be considered for registration at the plenary meeting.
#05-10: Wagoner: Resubmit vulnerability descriptions with changes as suggested in Meeting #5.
#05-11: Jones: Resubmit vulnerability descriptions with changes as suggested in Meeting #5.
#05-12: Michell: Review safety documents (e.g. 61508, DO178B) to look for safety hazards that might be treated in the TR.
#05-13: Plum: Provide wording for "RSIZE_T" and "Verifiably representable" for vulnerability description XYE.
#05-14: Benito: Investigate CWE 365 (referenced in vulnerability description XYI) to determine what is intended.
#05-15: Moore: Contact SC27/WG4 and suggest that an appropriate interface between their work and our work is for them to suggest capabilities that should be included in programming languages, language libraries, and APIs for use by those performing application security.
#05-16: Plum: Contact ECMA TC39/TG1 regarding security of ECMAScript.

5.4 Thanks to Host

We thank Steve and SCC for hosting the meeting.

6. Adjournment