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

Draft Minutes Meeting #44
ISO/IEC JTC 1/SC 22/WG 23: Programming Language Vulnerabilities
15-16 April 2016


Meeting Location :

British Standards Institute

BSI Group,

Chiswick Tower,

389 Chiswick High Road,

London, W4 4AL, UK

1 Opening activities

1.1 Opening Comments

1.2 Introduction of Participants/Roll Call

Stephen Michell convenor

Clive Pygott UK, MISRA C++ Liaison

Robert Seacord NCC Group

David Keaton WG 14 Liaison

Larry Wagoner US,

Erhard Ploedereder WG 9 Liaisom

1.3 Procedures for this Meeting

1.4 Approval of previous Minutes (meeting 43, document N642)

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

Action log updated.


1.6 Approval of Agenda [N 0647]

Approved.

1.7 Future Meeting Schedule


2017

pre-mtg-51

TBD November 2017

Teleconference (UTC 2000, 2 hr)


post-mtg-50

TBD October 2017

Teleconference (UTC 2000, 2 hr)


#50

TBD August 2017

In-person (with SC 22 Plenary)


#49

TBD June 2017

In-Person (2 day)


post-mtg-48

TBD May 2017

Teleconference (UTC 2000, 2 hr)


#48

TBD April 2017

In-person (2 day)


pre-mtg-48

TBD March 2017

Teleconference (UTC 2100, 2 hr)

post-mtg-47

TBD February 2017

Teleconference (UTC 2100, 2 hr)

#47

23-24 January 2017

In-person (2 day)

with pre meeting telecon 21 Nov 2016 (UTC 2000 2 hr)


2016

#46

15-16 Sep 2016

Vienna, Austria (with SC 22 Plenary)

pre mtg telecon 15Aug 2016(UTC 2000)

post mtg telecon 11 October (UTC 2000)

#45

14-15 June 2016

Pisa, Italy with Ada Europe

with pre mtg telecon 16/5/16 UTC 1500)












2. Liaison Activities

2.1 SC 22

2.2 PL 22 (Open)

INCITS executive meeting this week.

2.3 PL22.3/WG5 (Fortran)

No information

2.4 WG4 (COBOL)



2.5 WG9 (Ada)

Finished the first round of edits and given to WG 9 convenor for consolidation. Expect the document to be returned for the Meeting 45.

2.6 PL22.11/WG14

TR 24772-3 was presented at the WG 14 meeting. WG 14 declined to be the primary owner of Part 3, but encouraged Wg 14 experts to give edits to Clive Pygott.

We have a discussion about the WG 14 concerns and the role of TR24772-3 guidance in competition

2.7 PL22.16/WG21 (C++)

Some interest has been expressed by individual C++ experts. We anticipate further developments.

2.8 Ecma International, TC49/TG2 (C#)

No information.

2.9 Ecma International, TC39 (ECMAScript)

No information.

2.10 MISRA ©

In process of issuing a new version that addresses C99 issues. Using the Secure C coding rules as the new base, with some interpretation.

2.11 MISRA (C++)

Considering using the C secure coding rules. Developing a TC for the existing guidance. Want to look at static analysis tools.

2.12 SPARK

No information.

2.13 SC7/WG19 (UML)

No information.

2.14 SC27/WG3, WG4 Security

No new information.

2.15 Other Liaison Activities or National body reports

3. Document Review

3.1 TR 24772-1 Vulnerabilities, language independent

Document N645, N646


We examine document N0646, Time-related vulnerabilities. We agree that these are important issues, but questions were raised about the placement (sect 7 vs section 6) and if they are close enough to our focus to warrant the visibility of the TR. Members are asked to review and consider for the May Webex session. We discuss the boundary between section 6 and 7. Section 7 is closer to design flaws while section 6 are features that the programming language can provide solutions to obviate the problem.


AI 44-5 Steve, clean up time vulnerabilities (N046?) by moving terminology to section 3, make the writeups more concise. Also add back the notion of monitoring low-powered devices to the resource consumption.


AI44-6 Erhard – Examine section 7 and make recommendations on the general categories “language”, “operating system” and “application design” and how current vulnerabilities fit within those categories.

3.2 TR 24772-2 Ada language specific part

Waiting for a proposal from SC 22/WG 9

3.3 TR 24772-3 C language specific part

Document N0643

AI 4-2 Clive, TR 24772-3 N0643, add a reference to ISO IEC (POSIX STD) in section 2 Normative References.

AI 44-3 Clive, TR 24772-3 N0643, In sect 5, the table of aggregated advice, ensure that the referenced source for each advice is consistent with the changes made.

We review the table in section 5 and rework the wording for the “top 10” mitigations. The results of this work are in N0649 with change tracking enabled.

Discussions of existing coding standards for C, and the relation of TR 24772-3 to them.

Coding standards that we can reference

MISRA C (latest) x

CAST China Academy of Space Technology

CERT-C (2014) x

CMSE China Manned Space Engineering

CWE

EADS European Aeronautic Defense and Space company (proprietary)

FSB582-C NASA

GJB Chinese Military C coding standard x

HIS Herstellerinitiative In Software

JPL Institutional Coding Standard for C

NETRINO Embedded systems company (proprietary)

Secure C TS17961 x

UML

VSOS Marine software company (proprietary)

There are a similar set for C++

AI 44-4 Larry and Stephen - Take 5 6.x.2 sections and look for quotes from some of these and write up possible new clause 6.x.2

3.4 TR 24772-4 Python language specific part

Discuss at meeting 41.

3.5 TR 24772-8 Fortran

Document [N0560] needs review.

3.6 TR 24772-X C++

Consider document [N0582]


3.7 Bibliography and normative referencing for each TR24772 Part

Issue about wording changes and clause 3 changes due to ISO online browsing platform. Section 2 is to only reference technical documents that we use in that manner. No references to terminology standards are necessary, but how do we reference that terminology? How do we provide guidance to use the OBP? All other references are made in the bibliography.


AI 44-1 Steve – In section 3 Normative references, do we continue to reference ISO IEC 2382:2015, or make a specific reference to the OBP?

4 Strategy (Face to face meetings only)

Discussion about how TR 24772-3 C fits in with other (well known) C coding standards. Erhard feels that we need to highlight the choices to be made, and not provide rules that may be controversial. Referencing well-known standards may let us highlight the different approaches. The same strategy may work for C++, and Java. Other languages will depend upon the availability of openly available (and multiple) coding standards. It will also depend upon the support of a language-specific committee.

This may affect the incorporation of new languages (i.e. the availability of a language committee and/or the availability of openly available coding standards) but we will decide on a case-by-case basis.

Possible missing vulnerability

When do we stop adding vulnerabilities? Suggestion, (Intention) Meeting 46 in Vienna could be the cutoff for identifying new vulnerabilities to be added. This includes aggregation or subdivision. Any vulnerability gross changes after this time should be avoided and not having objection from language partners. By meeting 48, we expect that Part 1 will be frozen.

How do we acquire more resources for other parts and general technical expertise and interest?

AI 44-7 – Steve write up convenors report to SC 22 and communicate it to meeting 45.

What are we trying to do? Increase the relevance of TR 24772 in the programming world.

CS’s should reference us. We are not in competition because we address the underlying causes of safety and security

We should be talking with the analysis tool community and safety and security communities.

AI 44-8 Steve (Erhard for ides) – draft letters to MISRA, CERT (and others), RTCA, developers of coding standards, IEC 61508 (IEC functional safety) community about mutual referencing and support.

AI 44-9 all – help find contacts as recipient for said letters.

5 Publicity (Face to face meetings only)

See sect 4. Focus energy on increasing awareness of our work in communities that can use it. Get CWE, etc referencing our TR (again).

6 Other Business

6.1 Review of Assignment of responsibilities


7. Resolutions and Action Items

AI 44-1 Steve – In section 3 Normative references, do we continue to reference ISO IEC 2382:2015, or make a specific reference to the OBP, and how do we do that?


AI 4-2 Clive, TR 24772-3 N0643, add a reference to ISO IEC IEEE 99??(POSIX STD) in section 2 Normative References.

AI 44-3 Clive, TR 24772-3 N0643, In sect 5, the table of aggregated advice, ensure that the referenced source for each advice is consistent with the changes made.

AI 44-4 Larry and Stephen – In TR 24772-3, take 5 6.x.2 sections and look for quotes from some of the referenced coding standards (in section 3.3) and write up possible new clause 6.x.2


AI 44-5 Steve, clean up time vulnerabilities (N046?) by moving terminology to section 3, make the write-ups more concise. Also add back the notion of monitoring low-powered devices to the resource consumption, for considerations meeting 45.


AI44-6 Erhard – Examine section 7 and make recommendations on the general categories “language (sect 6)”, “operating system (uncharted)” and “application design(sect 7)” how current section 7 vulnerabilities fit within those categories, and whether we need a new clause.


AI 44-7 – Steve write up convenor’s report to SC 22 and communicate it to meeting 45.

AI 44-8 Steve (Erhard for ideas) – draft letters to MISRA, CERT (and others), RTCA, developers of coding standards, IEC 61508 (IEC functional safety) community about mutual referencing and support and how we can work together.

AI 44-9 all – help find contacts as recipients of the letters in AI 44-8.

8. Adjournment