ISO/IEC JTC 1/SC 22/WG 23 N0274
Draft Minutes: Meeting #15
ISO/IEC JTC 1/SC 22/WG 23: Programming Language Vulnerabilities
15-17 September, 2010

Corrected and approved: 14 December 2010

Meeting Times:

15 September 2010: 13:30 to 17:00
16 September 2010: 09:00 to 12:00 and 13:30 to 17:00
17 September 2010: 09:00 to 12:00 and 13:30 to 17:00

Meeting Location:

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

Teleconferencing Details:

Meeting ID: 060648
Meeting Password: 06061948


Dial 781-271-6338 (x16338) from the Bedford, MA region.
Dial 703-983-6338 (x36338) from the Washington DC region, Nationally or Internationally.

TO ATTEND THE MeetingPlace Collaboration CONFERENCE:

1. Go to:
2. Click on Attend Meeting.
- Accept any security warnings you receive and wait for the Meeting Room to initialize.
3. If MeetingPlace Collaboration Window does not automatically open, press connect.


Visit to test your web browser for compatibility with the web conference. Follow
this link to the browser test link on the page.

Meeting Logistics:


Local Contact information:

Stephen Michell


1. Opening activities

1.1 Opening Comments (Moore, Benito)

The meeting was called to order at 1:30 pm on Wednesday, 15 September 2010.

1.2 Introduction of Participants/Roll Call

Canada (Steve Michell), Japan (Kiyoshi Ishihata), US (Jim Moore-HOD, Larry Wagoner, Tom Plum), and the WG9 Convener (Joyce Tokar) attended the meeting. Russia (Vladimir Rubanov) observed for part of the meeting. John Reid, convener of WG5 (Fortran) observed for part of the meeting.

UK (Clive Pygott) phoned in for parts of the meeting, as well as Bob Karlin of the US.

John Benito attended as convener and Jim Moore as secretary.

1.3 Procedures for this Meeting (Benito)

In general in WG 23, we do not perform voting. Anyone who attends is entitled to speak.

1.4 Approval of previous Minutes (Moore) [N0261]

They were approved without objection.

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

The status of the open action items was updated.

1.6 Approval of Agenda [N0255]

The agenda was approved without objection.

1.7 Information on Future Meetings

1.7.1 Future Meeting Schedule
WG 23 #16 2010-12-14/16 San Diego, California, US WG 23 Meeting #16 Logistics [N0252]. Preliminary agenda [N0256]

It should be noted that the above meeting is scheduled on Tuesday, Wednesday, Thursday.

WG 23 #17 2011-03-23/25 NEW Madrid, Spain WG 23 Meeting #17 (in conjunction with WG21) Logistics [N0277]
WG 23 #18 2011-06 TBD probably 19/20 Edinburgh, Scotland, UK Possibly in conjunction with WG9  

Meeting #19 will probably be colocated with the SC22 plenary in Copenhagen.

1.7.2 Future Agenda Items

Note the action item (#13-07) re MISRA comments.

2. Reports on Liaison Activities

2.1 SC 22

Steve Michell reported that:

The rules for progressing documents have changed as a result of the harmonization of JTC 1 procedures with ISO/IEC procedures. This will have little effect on Technical Reports of type 3, which are now simply termed as "Technical Reports".

2.2 PL22.3/WG5 (Fortran)

John Reid, convener of WG 5, briefly visited the meeting. He reported that they have finished Fortran 2008 and it should be published soon. They are also working on a TR for improved interoperability with C. He also reported that it is his belief that the working group will eventually agree to inclusion of a Fortran-specific annex in the WG 23 Technical Report.

2.3 PL22.4/WG4 (COBOL)

Bob Karlin reported that the revision of Cobol is out for FCD ballot. There are reasonably good prospects for a Cobol annex to the WG23 document.

2.4 WG9 (Ada)

Received from Erhard Ploedereder via email:

The Ada Annex was made available to WG23 in time for the Kona meeting. Early feedback is appreciated by WG9, whose next meeting is on Friday, 29 Oct 2010, in conjunction with the SIGAda conference in Fairfax, Virginia, USA. (The meeting thereafter will be in Edinburgh, UK, on 24 June 2011.)

The SPARK Annex got delayed by a series of late comments too comprehensive to be dealt with in time for the June meeting of WG9. WG9 and its rapporteur group HRG will process the Annex on a separate time schedule.

The secretary noted that the SPARK Annex was subsequently submitted.

Joyce Tokar added that the latest amendment to the Ada standard is nearly ready for balloting. WG 9 will then commence an overall revision of the standard. The draft Ada annex and SPARK annex for 24772 were contributed and are on the agenda for this meeting.

2.5 PL22.11/WG14 (C)

John Benito reported that their revision to the C standard will enter CD ballot in the next few months. They plan to follow the new process for document progression.

2.6 PL22.16/WG21 (C++)

Tom Plum reported that WG 21 will meet in Madrid, colocated with WG23. Their top priority will be to complete their FDIS. It is hoped that WG 21 will consider the possibility of a language annex for 24772 after they have processed the FDIS balloting results.

2.7 Ecma International, TC49/TG2 (C#)

Tom Plum reported that they have not identified someone to draft an annex.

2.8 Ecma International, TC39 (ECMAScript)

Tom Plum reported that ECMAScript appears to have done a good job in closing up vulnerabilities. However, he has not been able to identify someone who could draft an annex. The language is identical to the JavaScript language, so a JavaScript expert would be suitable for drafting an annex.

2.9 MISRA (C)

See 2.11.

2.10 MISRA (C++)

See 2.11.

2.11 MISRA L

In an email note dated 15 September 2010, Clive Pygott reported:

... here's what's happening with MISRA:

As an aside, the UK's Safety Critical System's Club (an industrial SIG run from the University of Newcastle) is holding a 2 day safety critical software conference, with half day workshops for both MISRA C and MISRA C++.

2.12 SPARK

Joyce Tokar reported that the SPARK annex was drafted and forwarded to WG23. It is on the agenda for this meeting.

2.13 MDC (MUMPS)

No report.

2.14 SC7/WG19 (UML)

No report.

2.15 Other Liaison Activities or National body reports

In an email note dated 3 September 2010, Ben Brosgol reported:

I've tried to get some volunteers for this effort from JSR-286 (RT Java) and JSR-302 (Safety Critical Java) without much success, but maybe I need to be a bit more aggressive in my recruitment. Both JSRs have biweekly calls so I will bring up the subject again, emphasizing the need to follow through. But to be honest, the winter meeting in San Diego may be more realistic than the upcoming meeting in Ottawa, in terms of having something tangible, or at least a plan / schedule.

I think the JSR-302 group is the one that is most likely to be interested in participating, and (as you are probably aware) Doug Locke is the spec lead on that effort and he may be sympathetic.

If there are WG23 deadlines that I should be aware of, please let me know. I apologize for not paying as much attention as I should to the WG23 work, but hopefully I'll be able to organize the work and produce the annex as originally planned.

3. Document Review 

3.1 Convener's business plan

N0266 2010-07-08   Business Plan and Convener’s Report [for the forthcoming SC 22 plenary meeting [pdf]

It was decided that there was no need to discuss this.

3.2 Revised draft for publication of edition 1 of TR

N0267 2010-07-23 Supersedes [N0257] Revised draft of 24772 submitted for publication [zip]. (The document is a PDF in an encrypted zip file in order to protect it from public view.)

It should be noted that this document is encrypted. Participants may decrypt the document but should use it only for the purposes of standardization pending approval of our request for free availability.

3.3 Language-specific annexes for Ada and SPARK

N0275 2010-08-31   Draft language-specific annex for SPARK, contributed by SC 22/WG 9 [doc, pdf]
N0258 2010-06-22 Replaces [N0205]. Draft language-specific annex for Ada, contributed by WG 9 [doc, pdf]

Several comments were made during discussion:

Some exemplar markups of the SPARK Annex [N0275] were saved as [N0281].

We considered the suggestion that "implications for standardization" should be removed from the language annexes. Existing text would be examined to determine if it can be generalized and moved into the language-independent section of the document. We decided that any bibliographical information and any "plans for standardization" should be gathered and put into one place, rather than being part of each individual vulnerability description in the annex.

We decide that each description in the language-specific annex should have only two subsections:

Temporarily, bibliography and plans for standardization can be included but they will eventually be gathered into distinct sections.

There should be a preamble to the language-specific annexes that explains what is in each section.

Here is the summary of edits that Joyce Tokar collected during the discussion:

  1. Add a statement in the SPARK annex to explain what "HIDE" is much like the "Unsafe Programming" in Ada.
  2. In both Ada and SPARK, identify the 'unsafe' programming as NOTE.
  3. Move all of bibliography to the beginning of the document.
  4. Move all of the plans for standardization to a new section (section 4)
  5. When the vulnerability does not exist in the language, say that and very little more. If the vulnerability does not exist and there is a concrete statement to say why
  6. Make sure all of the things that the language does to mitigate the vulnerability goes in section 2 - rename this section to "Applicability to Language"
  7. Make sure section 3 is written in a voice to give guidance to the programmer on what they need to do to avoid the vulnerability - rename this section to "Guidance to Language Users"
  8. Remove the "SPARK is designed to" to say "SPARK does "

It was agreed that WG 23 should take the existing annexes, rework them into the new format with the edits described above, and send the result to the other working groups for comment and correction. John took Action Item #15-10 to do this.

3.4 Template for language-specific annexes

N0271 2010-08-31 Replaces [N0217] Revised format for language-specific annexes, from ISO/IEC TR 24772:2010 [html]

Moore took Action Item #15-01 to revise N0271 in accordance with the previous item.

3.5 Summary tables of vulnerabilities

N0279 2010-09-10   Prototype table summarizing vulnerabilities, contributed by Jim Moore, in response to Action Item 14-04 [docx, pdf]
N0280  2010-09-14    Prototype table summarizing vulnerabilities, contributed by Steve Michell, in response to Action Item 14-05 [xls

We looked at the prototype tables prepared by Steve and Jim. There were concerns that a tabular approach may tend to over-simplify difficult issues. There was no consensus that tables similar to these should be included in the TR.

3.6 "Slimmer" version of 24772 as baseline for Edition 2

N0268 2010-08-12   "Slimmer" version of 24772 proposed as the baseline for Edition 2, contributed by Jim Moore, responding to Action Item #14-10 [docx, pdf]

John asks if we could replace Annex D.3 [as numbered in the slimmer version] with an index. There was no objection. [However, later in the meeting a use was found for the table--tracking the lineage of descriptions that are combined and split, and accounting for "retired" 3-letter codes. For now, it will remain.]

We decide to proceed with using N0268 as our baseline, understanding that there may be future comments to add material to it.

Considering the ordering of descriptions, we decide to swap the current D.1.5 (referring to N0268) and D.1.6, so that the type system is the first category of vulnerabilities treated. After further consideration, we decide on the ordering shown in N0282.

Jim took Action Item #15-02 to incorporate these comments into N0268 and provide the result [N0283] to the editor for use as the new baseline.

3.7 Language-specific annex for C

3.7.1 Proposed language-specific annex for C

N0276 2010-09-10 Replaces [N0259] Revised draft language-specific annex for C, contributed by John Benito, David Keaton and LarryWagoner [pdf]

There were comments on the example in C.7.2. John took Action Item #15-11 to change it.

3.7.2 Floating point

There was a brief discussion of floating point. Tom Plum thinks that our current treatment is good enough. Jim suggested that we might expand it to include some common mistakes:

We decide that additional discussion is appropriate before we make a decision.

3.7.3 Dead code

David raised the issue of dead code. He is concerned that the description overlooks legitimate reasons for dead code. David takes Action Item #15-03 to propose a revision to XYQ that is more even-handed.

3.8 Proposed draft NWIP for software security APIs

N0273 2010-08-31   Proposed draft NWIP for software security APIs, contributed by Larry Wagoner [doc, pdf]

It was sugggested that words like "safety" should be removed because they raise issues regarding where the work belongs. It was suggested that a working draft should be developed before the NWIP is balloted. It was suggested that the NWIP and working draft should be socialized with the US and Canadian shadow committees for SC 7 and SC 27 before the NWIP is balloted. Steve Michell suggested that Canada would be willing to submit the NWIP when the time comes.

3.9 Proposed new vulnerability regarding file uploads

N0269 2010-08-31   Possible new vulnerability, Unrestricted file upload (CBF), contributed by John Benito [pdf]

We decide to add this one to the draft. John was given Action Item #15-12 to add it.

We gave John Action Item #15-04 to review the various descriptions in Clause 7, along with this one, to determine if Implications for Standardization should be included, e.g. "provide library routines to assist in performing the checking."

Also, we gave John Action Item #15-05 to add to AJN the advice to eliminate control characters from file names.

3.10 Proposed split of XYR

N0272 2010-08-31   Possible new vulnerability descriptions from splitting XYR into two descriptions, contributed by Clive Pygott (Action item #14-09) [doc, pdf]

Both of the new descriptions should have new three-letter-codes. Also a few occurrences of "s" should be changed to "z". Also the cross-references should be checked. A remark should be added that finding unused variables may suggest an error in defining name scopes within the program. Also program maintenance may cause the previously unused variable to be used -- but in the wrong scope, possibly with erroneous results. We agree to make the proposed separation. John takes Action Item #15-08 to make the change.

3.11 Proposed combining of vulnerabilities related to buffer overrun

N0270 2010-08-31 Also see [N0278] Possible new vulnerability, Buffer overflow (HCB)--Language-independent and C versions, contributed by John Benito (Action Item #14-08) [pdf]
N0278 2010-09-10 Related to [N0270] Revision of C annex portion of N0270 [pdf]

It would be appropriate to add a description of all of the various terms that different sources have used to describe this vulnerability; the various terms should also appear in the index. We decide to make this change; the editor takes Action Item #15-07 to implement it.

3.12 Tracking changes in vulnerability descriptions

We decide that whenever a vulnerability is created by splitting or combining, there should be a NOTE identifying its ancestors. Also the table in Annex D might serve as a place for recording changes. John takes Action Item #15-09 to implement this.

4. Other Business

John wants to discuss moving AJN into the clause with application vulnerabilities. We agree that "external identifiers" should be removed from the current text; that the description should be renamed as "Resource names"; and that the description should be recoded as HTS and moved into the clause with application vulnerabilities. We should investigate writing a new vulnerability description dealing with the resolution of external identifiers. John takes Action Item #15-06 to accomplish this.

5. Resolutions

We reviewed the action items.

6. Adjournment

We thank Steve and the Standards Council of Canada for hosting the meeting, and for the dinner associated with the colocated plenary meeting of SC 22.

We adjourned at 10:15 am on Friday.