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

Meeting Minutes for Meeting #36
ISO/IEC JTC 1/SC 22/WG 23: Programming Language Vulnerabilities
26-27 June 2015

Meeting Location :

ETSIT-UPM, Avenida Complutense 30, 28040 Madrid, Spain
in conjunction with Ada Europe.

Meeting Times:

26 – 27 Jun 2015: 1400-2000 Friday June 26, 1100-2000 Saturday June 27

Agenda

1 Opening activities

1.1 Opening Comments

1.2 Introduction of Participants/Roll Call

Larry Wagoner (phone)
Uruena Pascual
Tatsuaki Takebe
Stephen Michell - Convenor
Erhard Ploedereder
Florian Schanda
Tullio Vardenaga
Clive Pygott (phone)
David Keaton (phone)

1.3 Procedures for this Meeting

1.4 Approval of previous Minutes

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

1.6 Approval of Agenda [N 0525]

1.7 Future Meeting Schedule

2. Liaison Activities

Not discussed at this meeting.

2.1 SC 22

2.2 PL 22 (Open)

2.3 PL22.3/WG5 (Fortran)

2.4 WG4 (COBOL)

2.5 WG9 (Ada)

2.6 PL22.11/WG14 (C)

2.7 PL22.16/WG21 (C++)

2.8 Ecma International, TC49/TG2 (C#)

2.9 Ecma International, TC39 (ECMAScript)

2.10 MISRA (C)

2.11 MISRA (C++)

2.12 SPARK

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

IS 17960 is in FDIS ballot.

Comments have been received from SC 27 based on ISO IEC Standards 15048 and 18045. These documents are about evaluating products for soundness. The submitter would like to extend the 17960 notion of signing down to object code and to machine implementation. Another issue is that the compiler will add extra information to the source code and directory path to the source code to the object code. The object code may be identical but the hash would differ. The submitter wants the compiler to guarantee the same source code for generation of hashes and keys.

We discussed this and decided that :

1. Other SC covers this (maybe SC 27)

2. Other factors such as compilation flags, time stamps and directory paths are included in most object code and would result in different signatures. We can visit this again.

Question (DMK) Does SC 27 want to work with us on this? We will have this discussion in October when WG 23 meets with SC 27 WG 3.

3.2 TR 24772-1 Vulnerabilities, language independent

Ideas for improving the current document.

1. Create section 5.4 Mitigations, and include various general mitigation techniques, such as sandboxing, executing in a virtual environment, and items found at https://buildsecurityin.us-cert.gov/resources/crosstalk-series/practical-defense-in-depth and at http://en.wikipedia.org/wiki/Layered_security

2. AI – all – Review the document that you are responsible for (or involved with) to consider vulnerabilities not yet documented in that Part and propose how each would be addressed in that document (Wording is not expected for analysis).

   We discussed the floating point vulnerability and create a new guidance and identify new vulnerability paths. See N0561 for details.

3.3 TR 24772-2 Ada

Start with document draft TR 24772-2 distributed to SC 22/WG 9 as N0549. Discuss and edit as appropriate with WG 9/HRG. The document was delivered to WG 9/HRG and distributed to members.

3.4 TR 24772-4 Python

Review material from Santiago Uruena Pascual for the Python document.

Reviewing Document – AI 36-1 - Santiago – update ToC, confirm applicability of normative references

3.5 TR 24772-8 Fortran

We examine the Fortran Part (N556), remove editing marks and republish as N0560. AI for Dan Nagle to begin updating the document to fill in unaddressed vulnerabilities and wording for existing vulnerabilities in light of changes to Part 1.

3.6 TR 24772-X C++

Review material from Clive for the C++ document.

How to handle the C++ Annex in the context of the C annex? We discuss 2 alternatives, re-documenting vulnerabilities captured in TR 24772-3 again, or normatively referencing TR 24772-3 and only stating “as in C” plus any new situations. Maybe could have shaded boxes that represent the text from TR24772-3, and only have the C++-specific text in normal font.

Discussion of the highlighting concept. We review a document that follows this approach. We decide to try this approach on the fledgling TR 24772-5 and review before of meeting 36.

The document was reviewed in detail. Changes are captured in N0563.

7. TR 24772-5 SPARK

   Altran (Florian Schanda) participated in the meeting. Meta-Issues about the SPARK Part discussed.

   Steve is reworking the SPARK Part to include information that was simply references to the Ada annex, and to follow the advice to editors. The document will be forwarded to Florian and to WG 9(?) as appropriate.

   AI 36-3 Steve and Florian – develop the Spark Annex to satisfy Altran and WG 23.

   Issues discussed:

• Task termination – cannot happen in Ravenscar tasking profile.

• Tasks sharing data because of safeness of variable access (PO’s, variable use pragma shared, only 1 writer and multiple readers.

• Discussion of general layout of SPARK annex Advice given to loosen the tie to Ada and to make it more free-standing..

• Discussion of terms “mitigation” and “prevents”. The Guidance to authors explains how to use these terms. We decide to recommend this for all annexes.

• Discussion of “soundness”, boundary between SPARK and non-SPARK and “assume”. AI – Florian – write text on unsafe verification with respect to SPARK.

• Considered 3 options. Decide to continue with shaded text idea, with qualification that the in case of discrepancy, the normatively referenced text applies. Include idea that the shaded text is copied for the reader’s convenience.

  Significant discussion of TR 24772-1 section 6.4 Floating Point. Items discussed and issues captured are contained in N0561

Advice to editors (N0555) – reviewed, updated as N0562. Placed into Standing Document S0005 final. Vote – unanimous.

3.7 JSF-TR comparison from Larry.

Document N0551 was reviewed. N0540, results captured in N0564. AI 36-4 – Steve – Migrate decisions captured in N0564 into N0561.

We identify a few issues that may result in new vulnerabilities. These are also captured in N0564.

JSF AV Rule 38 identifies a situation that it is possible to have multiple definitions or versions of a given subprogram in a system. (this is not the same as deriving or over-riding, it is having different versions of the same functionality with different behaviours. We believe that this may not be captured and require a new vulnerability (called Version Skew). AI 36-4 – Steve – investigate.

• JSF rule 35 is the issue about a header file including itself. This could be extended to a #define including itself. This is not recursion. Is there a vulnerability here?

• AI 36-5. Remove detailed references to JSF CS and place in C++ Part once started.

3.9 Business Plan

Submitted to SC 22 secretary.

4 Strategy (for face-to-face meetings)

What do we tell SC 27.

Who do we work with? Set up some time with WG 3 and WG 4

Do we have a continuous meeting in Jaipur or be at SC 27’s whim?

5. Publicity (for face-to-face meetings)

6. Other Business

4.1 Review of Assignment of responsibilities

5. Resolutions and Action Items

AI 36-1 Santiago – update ToC, confirm applicability of normative references

AI 36-2 – all – Review the document that you are responsible for (or involved with) to consider vulnerabilities not yet documented in that Part and propose how each would be addressed in that document (Wording is not expected for analysis).

AI 36-3 Steve - Migrate decisions captured in N0564 into N0561

AI 36-4 – Steve, Florian – iterate 6.4 (Floating Point) to ensure coverage of issues and relevance of issues captured for meeting 37.

AI 36-5 Larry, Clive - Remove detailed references to JSF CS and place in C++ Part once started.

AI 36-6 – Clive – Consider the creation of a vulnerability on OO associated with ways to break the Liskov substitution rule. Consider mistakes or attacks derived from using objects that require deep copying vs shallow copying. AV rule 77 & 76 & 82

AI 36-7 – Steve – consider JSW AV 85, add to [RIP] idea to ensure that you meet language expectations on constraints. Include the complete algebra.

AI 36-8 – Erhard – Consider JSF CS AV 89-97 for possible explicit guidance in [RIP] or possibly a new vulnerability. They are referenced from [RIP].

AI 36-9 – Clive – JSF AV 138 – prepose a placement for this issue, if it is a vulnerability.

AI 36-10 – Steve - Include general magic number vulnerability in [KLK]. Closed.

AI 36-11 – Erhard – Include downcasting (JSF AV 178) in a vulnerability

AI 36-12 – Steve – Add general conversions to [FLC] (currently numeric conversions) as listed in JSF AV 180

AI 36-13 – Florian – Write text on unsafe verification with respect to SPARK

6. Adjournment

Adjourned 27 June 2015 at 1930.