- 14 April 2010: 09:00 to 12:00 and 13:30 to 17:00
- 15 April 2010: 09:00 to 12:00 and 13:30 to 17:00
- 16 April 2010: 09:00 to 12:00
Dipartimento di Matematica Pura ed Applicata
(Dept. of Pure and Applied Maths)
via Trieste 63, I-35121 Padova
Tullio Vardanega
1.1 Opening Comments (Vardanega, Benito)
The local host, Tullio Vardanega welcomed us to the meeting. We will take coffee breaks at a bar about 5 minutes away; we will take lunch there also. There will be a common dinner after the first day of meeting.
1.2 Introduction of Participants/Roll Call
The following persons attended the meeting: Erhard Ploedereder (WG9 Liaison), Steve Michell (Canada Head of Delegation), Bill Spees, Larry Wagoner, Jim Moore (US HOD), John Benito, Clive Pygott (UK HOD), Tullio Vardanega (Italy HOD), Bob Karlin (by phone), Tom Plum
1.3 Procedures for this Meeting (Benito)
As usual there will be no formal votes, except possibly for an occasional straw poll. Everyone is welcome to speak at the meeting.
1.4 Approval of previous Minutes [N0227] (Moore)
The minutes were approved without correction.
1.5 Review of previous actions items and resolutions, Action Item and Decision Logs
Changes in the action item log since last meeting were briefly discussed.
1.6 Approval of Agenda [N0240]
We added item 4.1, a conversation regarding what work should be done after the current edition is submitted for publication. It was noted that the list of liaisons is inaccurate and obsolete. The secretary said that he would record them correctly in the minutes. The convener stated that he will correct his agenda template. With these changes, the agenda was approved. (As the meeting progressed, items 4.2 and 4.3 were added.)
1.7 Information on Future Meetings
1.7.1 Future Meeting Schedule
- Meeting #14: 28-30 June 2010, Kona, HI, USA
- Meeting #15: 15 (noon)-17 (5:00 pm) Sept. 2010, Ottawa, Canada (SC22 plenary meeting is 13-14 Sep; on 15 Sep, Sally Seitz will teach a course on the new directives.)
We discussed the problem of 17 September impinging on a Jewish holiday and determined that there was no practical alternative to meeting on that day.
The strategy for 2010-2011 is to meet frequently (either in person or by telephone) in order to progress a working draft to registration. After formal balloting begins, we will resume meeting at intervals of roughly six months.
ACTION REQUEST 13-01: Jim will try to arrange a meeting in San Diego for December 2010.
ACTION REQUEST 13-02: John will try to colocate a meeting with WG14 in April 2011 or WG21 in March 2011.
ACTION REQUEST 13-03: Tullio will investigate colocation with WG9 in June 2011 in Edinburgh. (Ada-Europe is June 22-24; WG9 is June 25; ARG is June 25-27; so WG23 would meet the previous weekend, June 19-21.)
1.7.2 Future Agenda Items
After the first draft of the second edition is prepared, the working group will reconsider the comments from MISRA L [N0250].
2.1 SC 22
Plenary meeting is upcoming in September. The new directives will be in place by then. Marisa Peacock has replaced Sally Seitz as Secretary of SC 22. There are both working groups and special working groups at the JTC1 level. We don't have any news yet regarding a 2011 plenary meeting of SC 22.
2.2 PL22.3/WG5 (Fortran)
No report. Dan Nagle has not been able to actively provide liaison for the past few weeks, but plans to resume his service.
2.3 PL22.4/WG4 (COBOL)
Bob Karlin reported that WG4 has not met for a year or so. Cobol remains interested in developing an annex, but is currently consumed in publishing their new edition of the Cobol standard. They plan for an FCD ballot in July.
2.4 WG9 (Ada)
Erhard reported that WG9 has drafted a revision of an annex for Ada. Apparently, this has not yet been transmitted to WG23 by the convener of WG9. Erhard believes that this represents a completed product. During the meeting, we received a reply from the convener of WG9. She is making some editorial changes to the draft annex and will circulate it to WG9 for approval. Afterwards, she will forward it to WG23.
2.5 PL22.11/WG14 (C)
John Benito reported that the C language specification standard is under revision. At their next meeting, they will decide whether to ballot their current draft. They are also publishing TR 24731-2, on dynamic bounds checking.
2.6 PL22.16/WG21 (C++)
John Benito reported that their revision of the language standard is currently in FCD ballot.
2.7 Ecma International, TC49/TG2 (C#)
No report.
2.8 Ecma International, TC39 (ECMAScript)
No report.
2.9 MISRA (C)
No report. They are working on a revision to incorporate C 99. There are many C 99 compilers available now, because it is necessary to get the XOpen brand.
2.10 MISRA (C++)
Clive reported that the MISRA C++ language working group is responding to feedback.
2.11 MISRA L (MISRA L)
No report. The convener mentioned that this is an effort to create some sort of language-independent document. MISRA L has submitted a request for a Category C liaison to WG23. The request has been approved by JTC 1.
2.12 SPARK
Rod Chapman sent an email note reporting that a language-dependent annex for SPARK had been drafted and currently rests with the WG9 convener. He is eager for the annex to be included in the next edition of the TR.
2.13 MDC (MUMPS)
No report.
2.14 SC7/WG19 (UML)
No report.
2.15 Other Liaison Activities or National body reports
None.
We turn to a discussion of the comments from the DTR ballot [N0243] and record recommended dispositions in [N0249]. We quickly disposed of all of the comments except the two from Canada. It was agreed to dispose the Canadian comments as "Noted. No action required for this edition." The Canadian proposals will be discussed in detail during the "discussion of future work" (item 4.1). The editor will revise the document in accordance with the disposition as well as write an abstract and will submit the TR for publication.
4.1 Discussion of future work
4.1.1 Discussion of Canadian proposal
The Canadian proposals from their DTR ballot are reproduced below:
Comment Proposed action The DTR does not contain a vulnerability for Input data validation. One of the largest sources of application vulnerabilities comes from unvalidated input. Some of the cases are covered individually, such as range checks on characters and unterminated strings, but the general case is not covered. We propose a new vulnerability for section 6 that covers the language vulnerabilities and one for section 7 that covers the application vulnerabilities. A first draft of the first vulnerability (for sect 6) is attached. The other will be sent to the next meeting of the WG for consideration.These vulnerabilities should be included in the next version of this report The lack of vulnerabilities for tasking, many OO conditions and many floating point vulnerabilities, as well as the lack of language-specific annexes, makes this document incomplete. We agree that this document should be published while these other vulnerabilities are being developed and that these items can be added to the next revision of this document. It is crucial, however, that these items be fully included in the next document, including annexes for languages such as Java and C#, as well as languages for which SC 22 is responsible. The vulnerability description proposed for Clause 6 was discussed and edited; it will appear in the initial draft of the second edition. The result appears below:
6.X Insufficient Input Validation [MEM]
6.X.1 Description of the application vulnerability
Software applications have predetermined expectations on the nature of input data that is to be processed. When the input data does not meet these expectations, unpredictable processing can result. Furthermore, input data that is carefully crafted to violate expectations can cause the application to fail in exploitable ways.
6.X.2 Cross reference
CWE-20 Improper Input Validation
6.X.3 Mechanism of failure
Applications make assumptions about the input data to be processed. Examples of these assumptions include:
- assumptions on the encoding or representation of strings or numbers
- assumptions on the range and set of legal values
- assumptions on the representation and internal consistency of aggregated data
- assumptions on the arrival rate and timing of data
- assumptions on the semantics represented by the data.
Data validation routines are generally very difficult to design and implement. Even carefully written validation routines may not check all assumptions. For example, there are usually implicit unchecked assumptions regarding encoding and representation. Furthermore, some inputs may be hidden from the validation routine or otherwise suppressed via library and system functions.
Input data that violates the developer's assumptions can cause for example:
- the application or the underlying runtime kernel, operating system and runtime libraries to incorrectly size or locate buffers, which may cause buffer overflows (see (appropriate other vulnerabilities) )
- range violations that permit errors to propagate or data structures to be inappropriately accessed
- generation of errors or exceptions that the application program cannot handle
- timing or order of execution issues
- incorrect interpretation of data when used in the application itself, or when passed to other applications or runtime components, such as command line processors.
Languages that permit automatic conversion between different representations of data are more susceptible to errors arising from improper data input. For example, if an application is expecting data encoded as ISO/IEC 8859 8-bit characters but the underlying system automatically converts 16-bit or multibyte characters, the size of buffer needed to hold that input will be different outside the application and inside the application.
Similarly, applications that assume a predetermined syntactic construct on input data may find the basic security premises violated.
6.X.4 Application language characteristics
All languages are vulnerable to this problem. Scripting languages are particularly vulnerable to input that has consequences for execution.
6.X.5 Avoiding the vulnerability or mitigating its effects
Input data must be validated in consideration of all of the possibilities for invalid data, including the possibility of malicious or incompetent data manipulation. Validation routines must be developed in knowledge of the preprocessing of input data that will be performed by the underlying processor prior to receiving the data.
Application developers should consider changing the method of input data collection to maintain the desired level of safety and security when assumptions on preprocessed input data cannot be sufficiently guaranteed.
Comprehensive unit and system test suites should be designed to exercise a wide variety of possibilities with particular attention to boundary cases, out of boundary cases, and cases that might be particularly damaging. Other verification techniques, including human and tool-based reviews, should be utilized to consider attack scenarios.
6.X.6 Implications for standardization
Languages or language systems should provide functionality to permit the examination and validation of all classes of input data. (In some cases, some of this functionality might have to be provided by the implementation in accordance with language specifications.)
Where data can be converted between types, languages should document the set of safe assumptions that can be made about such data.
Languages and language systems should provide mechanisms where raw data can be directly handled without implicit conversion or interpretation.
Languages and language systems should consider providing mechanisms for error conditions or exceptions to be raised when underlying assumptions about input data are violated.
It was agreed that application of "sandboxes" belongs in a different topic which may be addressed in the future.
Larry asked how the next edition of the TR might be organized. Jim suggested that all of the text prior to the current Clause 6 could be tightened up considerably. The editor said that he does not foresee an overall rewriting of the vulnerability descriptions. There was some suggestion that we might want to revisit the distinction between the current clauses 6 and 7.
We should consider proposals for changing the next edition and for complementary documents. We will consider proposals at Meeting #15. Participants are encouraged to discuss their ideas at Meetings #13 and #14 and via email to socialize their ideas.
Canada would like to discuss additional ways to gain expertise in other languages, including scripting languages.
4.1.2 C annex drafted by Larry Wagoner
Larry gave a brief introduction to the new draft [N0245] of the C annex. It has been extensively edited since the last version and can now be regarded as a stand-alone document, understandable in its own right. We review portions of the document and suggest changes to Larry for the next version.
ACTION REQUEST 13-04: The convener should, via email, call the group's attention to [N0245] and request each individual to review the draft and send comments to Larry by some given date.
ACTION REQUEST 13-05: The convener of WG23, who also serves as the convener of WG14, is requested to circulate the draft C Annex to interested members of WG14 for comment.
ACTION REQUEST 13-06: The liaison from WG9, Erhard Ploedereder, is requested to ask WG9 to forward the draft Ada Annex and draft SPARK Annex to WG23 for consideration in planning the second edition of TR 24772, prior to June 25.
We decide to change Annex E as follows:
Annex E
Template for language-specific annexes
(Informative)Each language-specific annex should have the following format, where <language> is the short name of the language being described and <x> is the corresponding sub-clause of the body of the document. For example, Ada.2 is the Ada-language-specific description of the same vulnerability as 4.2:
Annex <language>
Vulnerability descriptions specific to <language>
(Informative)<language>.1 Standards and terminology
<language>.1.1 Identification of standards and associated documents
[This sub-clause should list the relevant language standards and other documents that describe the language treated in the annex. It should not be simply a list of standards. It should do whatever is required to describe the language that is the baseline. In some cases, it might be a standard plus some other documents, or a standard minus the annex that lists deprecated features. It might include some explanation, such as "don't use any features that are undefined".]
<language>.1.2 General terminology
[This sub-clause should provide the general terminology used throughout the annex.]
<language>.1.3 General concepts
[This sub-clause should provide an overview of general concepts used throughout the annex.]
[Each vulnerability description should have the following format:]
<language>.<x> <Vulnerability Name> [<3 letter tag>][Every vulnerability description of Clause 6 of the main document should be addressed in the annex in the same order, starting with <language>.2, <language>.3, etc, even if there is simply a notation that it is not relevant to the language in question.]
[with corresponding changes in the succeeding text.]
4.1.3 Comments from MISRA L
We took a brief look at the comments from MISRA L [N0250]. Because MISRA L currently has no standing in SC22 and because the document passed DTR ballot, we did not act on the comments. ACTION REQUEST 13-07: The MISRA L comments will be reconsidered in the first draft of the second edition. Clive Pygott was requested to respond to MISRA L with WG23's thanks for the comments.
4.2 Discussion of free availability of the Technical Report [added during meeting]
We considered the JTC 1 criteria for free availability [N0251].
ACTION REQUEST 13-08: Prior to the June meeting, Jim should draft a request for free availability that focuses on the following criteria:
- (5) REFERENCE MODELS A: Standards which explain the relationships between existing standards (Catalogues of standards for sales promotion): Our language specific annexes will call out many of the standards from SC 22. Existing freely available material*, on similar subjects, has the effect of directing persons away from the ISO programming languages. Our material will have the effect of directing users toward the standardized languages because we emphasize adherence to the ISO standards as the most basic step to address the problem. [* Examples include cwe.mitre.org, cve.mitre.org, the SANS Institute top 25 list, the CERT website for C and C++, SCAP, nvd.nist.org, and OWASP.]
- (6) REFERENCE MODELS B: Architectural descriptions which describe frameworks to guide standards development, including profiles and taxonomies (Not implementable specifications and enhance awareness and influence of JTC 1): The specifications in the TR are not implementable but demonstrate the commitment of JTC 1 to meet the challenges of modern Information Technology.
- (8) SUBSETS:
Those Type 3 technical reports which describe basic visions and concepts in the technical domains covered by a set of standards (Enhance awareness and influence of JTC 1): Our TR explains how to use standard ISO programming languages in manners that are appropriate to the modern challenges of computing security and safety. We make direct references to the ISO language specifications.4.3 The way forward
The convener said that he would be happy if our next edition had three or four language annexes. We should not hold up publication of what is in hand. He said that we do not have the expertise to write the language annexes and that we need the sign-off from the language groups in order to complete them. Karlin reported that Cobol has "kicked around" some ideas but has not yet started drafting an annex; he is considering drafting a first pass himself. Larry believes that we should do first drafts in some cases, to get the process going. Steve says we need to recruit people with the expertise. Jim believes that users view the work more urgently and that we should recruit concerned users. Bob believes that academic expertise might be usable. Steve suggests that we should look for expertise in MITRE, NIST SAMATE, and tool vendors. Larry suggests a goal of including a scripting language. (Larry says that Fortify does static analysis on PHP, so it would seem to be a likely choice. JavaScript or ECMAScript might be an alternative.)
ACTION REQUEST 13-09: Tom Plum will contact the liaison representative from EcmaScript to determine if he might be willing to draft an annex.
ACTION REQUEST 13-10: Larry will contact Fortify (perhaps with the support of Paul Black) to participate in creating a draft annex for PHP.
ACTION REQUEST 13-11: Jim will contact Sean Barnum to learn if he has any contacts who might be suitable for drafting an annex on a scripting language.
ACTION REQUEST 13-12: Clive and Bill will investigate whether there are occurrences of vulnerabilities in hardware description languages. Clive will pursue some contacts at York and elsewhere.
Larry asked about the prospect for combining some of the vulnerabilities related to buffer overrun. Jim said he thinks we need a proposal for how a combined description might look. John said that he thinks we need a few annexes, so that we can see how the various vulnerabilities are treated there.
Jim noted that the Wellings paper enumerates as many as 35 vulnerabilities related to concurrency. We might want to decouple the maturation of those descriptions, if, in fact, there are a large number of them, from the evolution of the main document, by putting them in a distinct part. It was further suggested that any new or immature description might go into a second part and might be moved individually into the primary part as it matures. After discussion, it was concluded that we can create a second document as an internal working document. Much of our editing work will be devoted to improving and maturing the descriptions that are in the second document. As each description matures, it will be moved from the second document into the primary document.
5.1 Review of Decisions Reached
The minutes were displayed throughout the meeting and reviewed briefly at the end.
5.2 Review of Action Items
Jim scrolled through the minutes and reminded the participants of the various action items.
5.3 Thanks to Host
The group acclaimed its appreciation to Tullio for the fine hosting arrangements.
The meeting was adjourned on Friday.