Document ISO/IEC/JTC 1/SC 22/WG 23 N0569

Draft Minutes of Meeting #38
ISO/IEC JTC 1/SC 22/WG 23:
Programming Language Vulnerabilities
17-18 September 2015

Meeting Location :

INCITS, 1101 K St NW, Washington, DC 20005, USA

Meeting Times:

17-18 September 2015: 0900-1700 EDT (1300-2100 UTC)

Agenda

1 Opening activities

1.1 Opening Comments

1.2 Introduction of Participants/Roll Call

Stephen Michell - Convenor
David Keaton - USA / CERT
Haibo Li – CAT China
Erhard Ploedereder – WG 9?
Clive Pygott – UK, MISRA C++

1.3 Procedures for this Meeting

1.4 Approval of previous Minutes

Minutes for Meeting 36 (N0559) and 38 (N0574) approved.

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

1.6 Approval of Agenda [N 0578]

1.7 Future Meeting Schedule

2. Liaison Activities

2.1 SC 22

Subcommittee completed its 2015 Plenary on Tuesday 15 September 2015. WG 23 requested a formal project split of 22.24772 into 9 parts: Part 1 Language Independent; Part 2 Ada; Part 3 C; Part 4 Python; Part 5 Ruby; Part 6 Spark; Part 7 PHP; Part 8 Fortran; and Part 9 COBOL. The resolution for this item (15-07) passed unanimously.

WG 23 further requested that TR 24772-1, -2, -4 and -8 be commenced immediately, with a 36 month target date for publication, and a scope and editor assigned. The resolution for this item (15-08) passed unanimously.

2.2 PL 22 (Open)

2.3 PL22.3/WG5 (Fortran)

2.4 WG4 (COBOL)

2.5 WG9 (Ada)

Annex given to WG 9 and ARG to address. Will be subject of discussion at October WG 9 meeting.

2.6 PL22.11/WG14 C, liaison Clive Pygott

Draft of Part 3 is submitted. WG 14 confirmed TS 17961 Secure C coding rules. Expect to close open defect report on TS 17961.

2.7 PL22.16/WG21 (C++)

C++ members are creating guidelines to avoid problems in the language. Once this has been published, it may be useable to us.

2.8 Ecma International, TC49/TG2 (C#)

2.9 Ecma International, TC39 (ECMAScript)

2.10 MISRA (C)

2.11 MISRA (C++)

Looking at developing a Part for C++. Edited the outline for C++ language vulnerabilities. Looking at security for C/C++ - oriented towards inter-vehicle security.

2.12 SPARK

Waiting for a decision from Altran and WG 9 as to who does the update for TR 24772-6??

2.13 SC7/WG19 (UML)

2.14 SC27/WG3, WG4 Security

2.15 Other Liaison Activities or National body reports

3. Document Review

3.1 DIS 17960 Code Signing

3.2 TR 24772-1 Vulnerabilities, language independent

Review document N0578

We discuss OO vulnerabilities.

One vulnerability is “downcasting”. Some languages use dispatching to catch. We can create a vulnerability OO type conversion issues. Erhard to create initial draft.

Another vulnerability is “method not found” - mostly found in Smalltalk and in scripting languages. Problems come from dynamic typing or “ducktyping”

Constructors can lead to infinite recursion.

Thw results of the review is contained in [N-0583].

3.3 TR 24772-2 Ada language specific part

Document is in hands of WG 9 for updates.

3.4 TR 24772-4 Python language specific part

Review document N0558 Python language vulnerabilities contributed by Santiago.

3.5 TR 24772-8 Fortran

Review document N0560 Fortran language specific vulnerabilities

3.6 TR 24772-3 C

Review document N0580 which is an edit (from Stephen Michell) of N0554 for C language specific vulnerabilities contributed by Clive Pygott. Can we add any vulnerabilities for concurrency? Results of the review is contained in document [N-584].

3.7 TR 24772-X C++

As available

3.8 Standing Document 6

Review newly created SD 6 for correctness and formatting. We decide to review at meeting 40 in November. Everyone is asked to examine SD 6 before the meeting 40.

4 Strategy (Face to face meetings only)

1. At an earlier meeting, it was recommended that we consider developing programming standards to avoid section 7 (design) vulnerabilities. A discussion is needed as to what format such document(s) would take, what level of assurance they should target, i.e. scope, goals. Before going too far, should we draft an outline of a sample standard (or technical specification)?

   Larry agrees to develop an early cut at a document that consolidates section 7 guidelines as a secure, language independent coding standard.

4.2 An idea was presented this week to mine the guidance to user sections for common guidance, and to create a top N (N=10, N=25, etc) guidances that can be used by people creating programming guides. A reasonable place to put such guidance would be in section 5.

Larry presents and initial list, captured as N0584, which was discussed and updated.

3. Should WG 23 become the champion for Secure-(language=Java, C++, etc) coding rules? The rules going into section 5(?) may convert into such rules. Some reluctance was expressed that rules frame the security level that you are assuming. Another idea is to aggregate all rules in each language part and point to the sections where they are described.

   David mailed a draft TS 17961 for consideration and discussion at meeting 41 (Orlando).

4.4 We have an issue with moving to ISO eCommittee, in that people that contribute that are not registered as NB experts get unequal access to documents. Other committees do not use the N-numbering system the way that we have. They use the N-numbers for official (process) documents such as minutes and agendas, and for product versions ready for ballot. All other documents are “informal”. Would such a process work for us? We could set up a CVS or GIT or SVN system where it is easy and reliable to identify versions of a document as it is edited. General interest in the approach. Concern about implementation. Explore with WG 21 experiences in managing such systems. Prepare for discussion at meeting 41 (Orlando).

5 Publicity (Face to face meetings only)

6 Other Business

6.1 Review of Assignment of responsibilities

7. Resolutions and Action Items

AI 38-01 David Keaton, put reference to TS 17961 Secure C coding rules into TR 24772-3 draft.

AI 38-02 Larry Wagoner, create a draft set of Top 10 (or Top 25) User guidance (rules) for TR 24772-1 (closed)

AI 38-03 Stephen Michell, Kill IEEE grouper old site reflector.

AI 38-04 Stephen Michell, open-std.org reference to WG 23 points to grouper – get fixed. Also ensure that search references to vulnerabilities includes open-std.org. Also the page on open-std.org that names SC 22 committees misses us. (closed)

AI 38-05 Stephen Michell, determine experience with versioning systems from WG 21, etc.

AI 38-06 Stephen Michell, propose a rewording (generalization) of Part 1 clause 6.16 [PIK]

AI 38-07 Larry Wagoner, sanity check changed references to JSF rules in Part 1.

AI38-08 Clive Pygott, From Part 1 clause 6.29 TEX, Other issues around loop control variables are missing. See N0564 for JSF AV 198. & 199

AI38-09 Erhard Ploedereder, Part 1 clause 6.39 Fault tolerance and failure strategies – expand upon mechanisms of failure and guidance to users.

AI38-10 David, check Part 1 clause 6.6 conversion errors. Integrate migrated text from Part 1 into Part 3. Make sure this applies to general conversions.

AI38-11 Stephen, In Part 1 section 7, make guidance imperative throughout.

AI 38-12 Larry, Take Part 1 section 7 and initiate converting the material to a coding standard that puts the guidance up front and uses the vulnerability descriptions as rationale.

AI 38-13 Erhard, draft a few OO vulnerabilities, likely based on “downcasting”, “method not found” and “Constructors can lead to infinite recursion”.

AI 38-14 Santiago, Make changes as requested in N0586 (Python after meeting 38), including fixing bibliography.

AI 38-15 Santiago, Also analyze concurrency vulnerabilities for Python.

AI 38-16 All, Examine SD 6 before the meeting 40.

8. Adjournment