These minutes were approved at Meeting #5
The meeting was hosted by Tullio Vardanega and Ente Nazionale Italiano di Unificazione, Italy at
Dipartimento di Matematica Pura ed Applicata
(Dept. of Pure and Applied Maths)
Trieste 63, Padova
The meeting was conducted in meeting room #432, marked SALA RIUNIONI on the IV floor, in Tower B, marked SCALA B. Meeting information had been provided in N0057R.
These minutes are organized according to the agenda [N0063]. In some cases, the order of the record differs from the actual temporal sequence of the meeting.
The meeting was convened at 9:35 am on 30 April 2007 by John Benito, the convener. Our host, Tullio Vardanega, described the arrangements for the meeting.
Attending the meeting were:
There were no unusual procedures for this meeting.
There were no corrections to the minutes [N0055]. They were approved as circulated.
03-06: Benito added references to the language standards to the draft document. Both Fortran and Ada are a bit complicated. He asked for the correct citations.
Action #04-01, Jones: Provide his list of available coding standards for C, C++, Java, and Ada to Benito for addition to the Bibliography of the TR.
Action #04-02, Moore and Benito: Cull the decision log to retire implemented decisions from the log.
01-08: We closed it.
01-11: Benito will check again. Plum provided contact information for a possibility.
02-03: Not done yet. Ask Steve Michell if his previous contribution [N0042] was intended to satisfy this item.
02-06: Closed administratively
02-08, 02-09: No news
02-12: Closed. Document posted
03-01: Moore will check again.
03-02: Not successful; leave open.
03-03: SC 27 has suggested liaison. At this meeting, we should prepare a response to their proposed program of work.
03-04: Closed prior to the meeting. Done.
03-05: Remains open. (Discussion later in the meeting, rendered this as OBE. Moore administratively closed it.)
We added item 3.9 to discuss Larry Wagoner's documents. We added item 5.1 to respond to SC 27. The agenda was approved with these additions.
The next meeting, Meeting #5, is in Ottawa, Canada hosted by Michell. C++ has scheduled their meeting at the same time. So Plum will miss the first day of that OWGV meeting. [Subsequent to the meeting, document [N0076] was distributed; it describes logistics for the Ottawa meeting.]
Meeting #6 is scheduled for Kona, Hawaii [N0058] immediately following the SC22 plenary. However, SC22 is now planning to meet on Friday. Benito reported difficulty in booking from Singapore to Kona in time to attend the OWGV meeting. We decided to shift the beginning of our meeting to begin on Monday rather than Sunday.
Meeting #7 is already scheduled for Pittsburgh in the week of 10-14 December 2007. Action, #04-03, Benito: Select precise dates for Meeting #7 in Pittsburgh, PA.
Meeting #8: C is meeting in April in Delft. We think it is week of 14-18. Action, #04-04, Benito, Discuss with William Wakker the possibility of holding Meeting #8 in Delft or Amsterdam during April 7-11, 2008.
Meeting #9: This should be in the US. Action, #04-05, Benito, Check if INCITS is available for Meeting #9 during July 14-18, 2008.
Meeting #10: SC22 plenary will be in Milano. Action, #04-06, Benito, Ask Erhard Ploedereder if he could host a Meeting #10 in Stuttgart in September or early October 2008.
Meeting #11: Action, #04-07, Moore, Investigate co-locating with INCITS CS1 at a west-coast local for Meeting #11 (or possibly Meeting #9). Investigate colocating SC27/WG4.
Nothing was suggested. Later in the meeting it was suggested that Review of Action Items and Review of Decision Log could be merged in future agendas.
Decision #04-01: At the request of Nagle we decided that drafts of the evolving Technical Report should be made available whenever ready rather than waiting for the next pre-meeting or post-meeting mailing.
We set dates for the next post-meeting and pre-meeting mailings:
SC 27 is considering work on application vulnerabilities. The initial report of a study group [N0070] suggested a scope of work that would overlap with OWGV. Also, SC 27 has issued a liaison statement [N0071] suggesting collaborative work.
It was decided to discuss this under agenda item 5.1.
J3 has decided to add an annex to the standard listing processor dependencies (defined as everything other than the language specification). The OWGV activity has been helpful in motivating this work.
No report.
Moore has resigned as convener of WG9. The likely replacement is Joyce Tokar (US).
WG14 has decided to open the doors to a revision of the C standard because a critical mass of desired changes has accumulated. Many users never transitioned to C99 because of its emphasis of mathematical and scientific function. Business users are still using old compilers. Desired features include those for high reliability, predictability and safety. The report on OWGV activity was received favorably. They are interested in reducing the number of implementation-defined and unspecified features in order to reduce the cost of tooling. They may choose to define portability profiles. Compiler vendors would choose to conform to one or more profiles.
Action, #04-10, Moore and Seacord: They are requested to mention favorable feedback from J3 and WG14 in their upcoming presentation at the SSTC conference.
Nothing new to report.
No report.
Jones reported that there is a big push to get the document
out for review--which had been scheduled for January 2007. Review
is now scheduled for May. They want to complete the standard by
the end of the year. Their meeting is scheduled for October. It
is possible for persons to sign up for review if they sign a non-disclosure
agreement. There are are lot of C++ users from the automotive
industry and some
from aerospace who are keen to start using these guidelines.
No report.
No report.
No report.
There were none.
Jones presented his contribution [N0060]. Different language standards use different sets of phrases to describe the semantics of the language. Some languages use a model implementation. (He includes mathematical description as a type of model implementation.) The other category is prose. There are two types of prose description: some languages, e.g. C and Java, describe the behavior of the source code constructs; other languages, e.g. C++, describe how an implementation is to behave.
There is a single implementation of PERL so there is no uncertainty on which one is authorative. PHP has several implementations and so there is uncertainty over which one is the final authority.
The paper also suggests some ways of measuring quality. For the OWGV, the most important characteristic is whether one can infer behaviour from the description with confidence in the result.
The report goes on to discuss the phraseology used to express the normative nature of the specification.
Language specifications need to describe behaviour at some or all of the following "times": source code translation, linking, and execution. (There was discussion suggesting that some non-interpretive languages do not follow this model.)
Most languages contain areas where the behaviour is not completely specified. The question is how to recognize these areas within a language specification. If OWGV is to write generic guidelines, then we have to ensure that we recognize these areas and that we write guidelines in a manner that addresses them.
Jones suggested that he should apply a few fixes to [N0060] that were noted during discussion and that the result should be designated as one of the documents which future members of the group should read. Benito responded that we will evaluate the revision first before so designating the document.
Action #04-11, Jones: Revise N0060 in light of discussion at Meeting #4 and resubmit to OWGV.
Plum said that he originally wrote this document [N0062] to describe the work of OWGV to the C and C++ groups. The document was written concurrently with the most recent draft of the TR [N0061], hence does not use its terminology.
During discussion, it was suggested that OWGV is concerned with unexpected behaviour of a program, regardless of whether that behaviour is manifested as a safety problem, a security problem, or whatever.
From the safety point of view, every bug has to be viewed as a problem until proved otherwise. This might not be true from a security point of view.
It was suggested that we should use the term "code quality" rather than "software quality" because software quality is described differently in existing standards. Plum suggested that we could use Jarzombek's term "software assurance" with focus on "predictable execution" and "trustworthiness".
Plum found it useful to talk about "weakness" (security issue), "hazard" (safety issue), or "bug" (code quality issue). He went on to define a vulnerability in a programming language as "a feature or combination of features in a programming language that can cause or is strongly correlated with a weakness, hazard, or bug." (We added the underlined words during discussion.)
In the security world, after buffer overrun, the next dozen or so most common causes have to do with the failure to validate remote content, such as URLs, etc. Any language that permits invoking remote content is equally vulnerable. Many language libraries make it just as easy to invoke unvalidated content as valid content. Stated the other way around, no language makes it easy to validate remote content.
Seacord's [N0059] guidelines forbid the use of "system()" because of the inability to validate the content of the parameter. So one might recommend a "system_s()" function that requires the library to perform all known validations. (It's not yet clear what "all know validations" might mean.) It was suggested that there might be the ability to set up a profile of restrictions on remote content and the validations might be performed against that profile.
Plum defines "Critical undefined behavior" (CUB) as an undefined behavior which, no matter what component it appears in, can directly cause a weakness. So the basic strategy is for language standardizers to either minimize undefined behaviours or require that they not be critical as defined above. OWGV might want to ask each committee, "What are the CUBs in your programming language?".
Action #04-12, Benito: Update the draft TR [N0061] to use the definition of "language vulnerability" from Plum's paper [N0062] as amended during discussion by the addition of the words "or combination of features".
Plum described Ben Brosgol's paper [N0064]. It appears that Brosgol believes that the Java realtime effort is promising, but, for now, Ada is a better choice for safety-critical systems. There seems to be some market interest in RTSJ for realtime but not for safety-critical.
The DO-178B [RTCA-99] requirement for no unnecessary code ("easter eggs") seems to be a common thread between safety and security. On the other hand, unlike safety-critical code, security-critical code is often developed in ignorance of the security requirement. Perhaps the same test coverage requirement, MCDA, is suitable for security code.
Action #04-13, Benito: Add RTCA DO-178B to the bibliography of the draft TR.
Action #04-14, Benito: Contact vendors for Eiffel, PHP and Perl regarding participation in OWGV.
Benito noted that Paul Caseley's presentation [N0041] had been placed on the web site.
In Michell's absence, study of this contribution [N0054] was deferred and may be considered at the next meeting, which is scheduled for Ottawa.
We looked at the document [N0056] which proposes possible templates for generic descriptions of vulnerabilities. We decided to use Version 4 as our basis for improvement. We will revisit the question of the format after working a few more examples. Regarding the content of the current example, Nagle mentioned that the treatments here omit the idea of matching integer ranges to array sizes.
Action #04-15, Moore: Revise Version 4 of the template for vulnerability descriptions in N0056 to produce a new template N0072. [See action item log for complete description of changes to be made.]
Benito mentioned that Seacord presented this document [N0059] at last week's meeting of the C working group and that it was well-received. The document is being developed on a Wiki. Some members of the C working group offered to provide review and comments.
Action #04-16, Benito: Add a citation of Seacord's document [N0059] to the Bibliography of the TR.
Moore presented Wagoner's papers [N0066, N0067, N0068].
Regarding the use of CWE identifiers, Jones suggests that CWE is too detailed for the generic level of analysis that we will describe. Plum points out that CWE is an open, active, industry-wide effort to consolidate vulnerability descriptions.
Decision #04-02: When we describe a vulnerability that appears in CWE as a leaf node, then we should cross-reference our description to the CWE leaf node identifier.
We discussed the approach that Wagnoner proposes of finding vulnerabilities in the wild versus the approach that we are currently pursuing of finding possibilities for them via analysis. We looked at the items proposed in Part 3 of his document, [N0068].
After discussion, it is requested that Wagoner revise his proposal. It is believed that Wagoner should aggregate some of the cases as follows:
24, 25, 26, 37, 38, 39, 62, 64, 65, 250, 266, 267, 268: These deal with library functions that interface with a command interpreter and the environment under which the program is executed. One possible solution is providing additional library functions that assist in validating the parameters. We might encourage the development of APIs that provide suitable function.
192, 197: Might be separate; might be combined. Treatment of conversion of integer values.
231, 129: Buffer overflow.
476, 416: Dereferencing pointer containing an invalid value.
365, 368: Race conditions. We had previously decided not to treat concurrency issues in general, but might be willing to support specific cases that occur in the wild, such as these.
415 should be treated as a library issue, like the ones mentioned above.
550, 215: These are design (application) issues and are out of scope of OWGV.
219: This is an application issue and is out of scope.
230: This is a design issue and is out of scope.
256, 257: Possibly treat as a library issue to provide easy access to crypto techniques and storage cleaning function.
(The second instance of) 257: We can't find this one in CERT. Perhaps the number is a typographical error.
259: This might be a design issue or it might be solved with improved APIs along with 256 and 257.
401: We're not sure about this one. One could use a language with a garbage collecting memory model and/or explicit storage pools or one could perform extensive design and code reviews. Are there ways where the library could help? Are there ways in which tooling can help?
591: This seems like a library/API issue. For example, the swap image might be protected in some way.
446: Design issue. Out of scope.
570, 571,563: We suspect that these are commonly reported by tool vendors as potential problems but are not themselves actual vulnerabilities. On the other hand, these might be a human comprehension issues susceptible to soft guidelines.
Library issues are dealt with by suggesting that particular libraries might be changed to provide helpful function to be used by future coders.
Action #04-17, Wagoner: Revise his analysis in accordance with the discussion described in item 3.9 of Meeting #4 and resubmit as document [N0073]. The vulnerabilities should be described as instances of the new template N0072.
Plum thinks that we should expand section 1.4 of the current draft TR to describe the audiences to which we want to appeal. We would have two sub-sections, one dealing with security, and one dealing with safety. We would use Wagoner's analysis in the security section as a rationale. Nagle wants to be sure that our document is suitable for novice users who want to have high assurance that our software will work. This subject is revisited in item 3.8 and decisions are recorded there.
We discuss the working draft of TR 24772 [N0061] developed by Benito.
Benito has set up a Wiki with a log-in for those permitted to view documents and a log-in for those permitted to edit documents. For viewers, the login name is "owgv_view" and the password is "Guidance". The URL for the Wiki is:
http://wiki.dinkumware.com/twiki/bin/view/OWGV/WebHome
Action #04-18, Moore: Add a link to the Wiki to the OWGV web site. [Shortly after the meeting, this was completed.]
Among other things, we can use the Wiki for future evolution of the TR. After some discussion, we make the following Decision #04-03:
We started reviewing the current draft. Benito had revised the draft in accordance with decisions made at OWGV Meeting #3. (Some language standards have not yet been cited because the correct citation was not obvious.)
It was noted that clauses 5, 7 and 8 of the current draft may contain redundancies.
Decision #04-04: Clause 1.4 should describe 4 primary audiences -- safety, security, predictability (non-software-engineering-engineers-getting-it-right-the-first-time), and assurance.
Action #04-23: Try to integrate some of the other definitions from Tom Plum's paper, [N0062], into the definitions of the draft TR.
The intended relationship of clauses 5 and 8 is that 5 provides an overall organization, rationale, and motivation for the vulnerabilities, and 8 is a flat list of the vulnerabilities. Language-dependent annexes will match 8 on a sub-section by sub-section basis.
Clause 6 is intended to address the selection and provision of guidelines by ourselves and the writers of the language-specific annexes. This should be moved to an annex.
The current Clause 7 is actually a list of vulnerabilities. Each of the suitable ones should be re-proposed using the template for inclusion in Clause 8 as individual vulnerabilities.
Action #04-24, Michell: Re-propose the draft content of clause 7 of [N0061] as a list of proposed vulnerabilities, using the new template [N0072].
Action #04-26, Nagle: Rewrite the current clause 5, subclauses 5.1 through 5.4, of [N0061] with the goal of making it generic and consistent.
Action #04-25, ALL PARTICIPANTS: The current list of issues contained in subclause 5.5 of [N0061] can become candidates for inclusion in Clause 8. Persons who proposed them should be proposed again in the form of the new template, [N0072].
Clause 8 should become a flat list of vulnerabilities. Each subsection, 8.x, should be an instance of the agreed template.
Clause 8.2 of the current draft TR should instead become a clause 1.5 discussing how to use the TR.
Action #04-27, Benito: Implement the changes in the TR to create N0074.
At this point, we returned to the review of the previously reviewed template to determine if any sub-section headings from Section 8 should be incorporated into the template. We decided that:
These were all added to the list of changes provided in Action #04-15.
Decision #04-05: All proposals for vulnerabilities should be submitted in the form of Version 5 of the template [N0072].
[Subsequent to the meeting, Benito prepared "Editor's draft 3 of PDTR 24772, 01 June 2007", [N0074].]
SC 27 is considering work on application vulnerabilities. The initial report of a study group [N0070] suggested a scope of work that would overlap with OWGV. Also, SC 27 has issued a liaison statement [N0071] suggesting collaborative work.
Action #04-28, Moore: Send a response to SC27 in behalf of OWGV (cc-ing SC 22 leadership) that a part of their proposals overlaps the work of OWGV. Mention that we are preparing an invitation for co-located meetings of WG4 and OWGV. [Subsequent to the meeting, [N0075] was prepared and sent.]
Moore and the meeting attendees reviewed the decisions and actions reached earlier in the meeting.
There were no formal resolutions.
The participants warmly thanked Tullio Vardanega for the comfortable arrangements and the attentive hosting.
The meeting was adjourned before noon on Wednesday, 2 May 2007.