Subject: FW: N 3880-Summary of Voting on SC 22 N 3838, Registration for W DTR 24731-Information technology-Programming languages, their environment s and system software interfaces-Specification for Secure C Library Funct ions

From: Sally Seitz <[email-masked]>
Date: Thu, 24 Mar 2005 08:40:02 -0500

Please disregard earlier email.  The document location was not included.  My
apologies

ISO/IEC JTC 1/SC22

Programming languages, their environments and system software interfaces

Secretariat:  U.S.A.  (ANSI)

ISO/IEC JTC 1/SC22 N3880

TITLE:

Summary of Voting on SC 22 N 3838, Registration for WDTR 24731-Information
technology-Programming languages, their environments and system software
interfaces-Specification for Secure C Library Functions

DATE ASSIGNED: 

2005-03-24

SOURCE: 

SC 22 Secretariat 

BACKWARD POINTER: 

N/A 

DOCUMENT TYPE: 

Summary of Voting 

PROJECT NUMBER: 

22.24731

STATUS: 

The results of this ballot are forwarded to SC 22/WG 14 for review,
production of a disposition of comments report, and preparation of the DTR
text.  The comments of the United Kingdom can be found at:
http://www.open-std.org/jtc1/sc22/def/n3880.pdf
<http://www.open-std.org/jtc1/sc22/def/n3880.pdf> 

ACTION IDENTIFIER: 

ACT 

DUE DATE: 

N/A 

DISTRIBUTION: 

Text 

CROSS REFERENCE: 

SC 22 N3838

DISTRIBUTION FORM: 

Def 

Sally Seitz

ANSI

25 West 43rd Street

New York, NY  10036

Telephone:  (212) 642-4918 

Fax:             (212) 840-2298 

Email:  [email-masked] 

_____end of cover page, beginning of PDTR registration summary______________

SUMMARY OF VOTING ON

Letter Ballot Reference No:  SC22 N3838

Circulated by:                JTC 1/SC22

Circulation Date:            2004-12-14

Closing Date:                 2005-03-14

SUBJECT:  Summary of Voting on SC 22 N 3838, Registration for WDTR
24731-Information technology-Programming languages, their environments and
system software interfaces-Specification for Secure C Library Functions

The following responses have been received on the subject of registration: 

"P" Members supporting registration without comments 

6(Czech Republic, Denmark, Finland, France, Italy, Republic of Korea)

P" Members supporting registration with comments             

3 (Germany, Netherlands, United States)

"P" Members not supporting registration

2(Canada, Japan)

"P" Members abstaining                   

2 (Switzerland, United Kingdom)

"P" Members not voting                   

7 (Belgium, China, Egypt, DPR of Korea, Romania, Russian Federation,
Slovenia, Ukraine)

National Body Comments

Canada

Comments on WDTR 24731 "Specification of Secure C Library Functions"

Canada does not agree with the use of the word "secure" in the title

of this document. This word carries considerable baggage for the

safety and security communities and implies functionality that is 

not provided. We would suggest alternative terminology, such as 

"bounded".

Some of the functions provided exist or conflict with functions

provided in other domains, such as POSIX or SUS. If the behaviour is

different than these specifications, then programs that attempt to use

them may be incorrect. Even if the behaviour is the same, then the

pre-existing specification must be respected.  Examples of such

functions are:

    strtok_r, strcpy_s and strcat_s.

In particular, strcpy_s provides identical functionality to strlcpy

which has been in use for some time.

Special mention is required of strerror_s. A mechanism is required to 

predetermine the size of the string to be returned so that the buffer

can be preallocated.

Special mention is also made or "rand". Saying that cryptography

methods must be used is insufficient. The function specification

ignores several issues, such as blocking, enthropy and seeding of such

functions. 

Special mention is made of strtok_r. This function should clearly

state that any string to be read by such a function may already be

effectively unbounded, and while it may be bounded by the buffer in

strtok_s, the effects of inputting the original unbounded string may

already have occured.

Germany

German Comment on document ISO/IEC JTC 1/SC 22 N3838

ISO/IEC WDTR 24731

Information technology-Programming languages, their environments and system
software interfaces-Specification for Secure C Library Functions:

1) sprintf_s and other read functions with the exception of strnlen need to
be addressed somehow.

2) it is worth to consider, whether strncpy_s and strncat_s variants  with
one parameter for length should be added.  Zero-termination is in that case
assumed.  

3) it is worth to consider offering a feature, simply aborting the program
upon buffer length overrun.  Such an option could be activated conditionally
via #pragma or #define. 

(End of comment)

Japan

As already described in our comment on NWIP ballot, we think it is extremely
hard to make the C programming language secure by just adding a set of new
functions leaving the existing insecure ones untouched. To make the C
programming language truly secure it is necessary to abolish the existing
insecure features like pointer operations and some dangerous functions. We
strongly request WG14 to produce the rationale or annex which clearly states
the following points:

1) Clearly state the policy and criteria for introduction of new functions
For example, we think that gets_s() is redundant and should be eliminated
from the TR because the functionality of gets_s() can be covered by existing
fgets() function. So, please make clear the reason of adding gets_s()
besides fgets().

2) Clearly and concretely state what kinds of security hole exist in the
current ISO C standard(syntax and libraries).

3) Clearly explain what kind of vulnerability is fixed for each proposed
function one-by-one.

 For example, we cannot understand what is improved in wctomb_s() from the
original wctomb(). Please provide the explanation of the advantage of
wctomb_s() over wctomb().

4) Give the guide for secure programming by using the proposed functions.

Netherlands

The Netherlands votes 'yes' on the Registration of WDTR 24731 with the
following comments:

1 - Section 3.1, the definition of the term 'diagnosed undefined behavior'
is unclear; change to behavior, that is invoked by the use of a nonportable
or erroneous program construct or of erroneous data,and that an
implementation shall diagnose by, in effect, calling an
implementation-defined function.

2 - Section 5.3, para 2; replace 2nd sentence by If a function that has
parameters of type rsize_t is called with values for those parameters that
are greater than RSIZE_MAX the behaviour shall be diagnosed undefined
behaviour.

3 - Section 5.3, para 4, last sentence: replace 'diagnosable' by
'diagnosed'.

4 - Section 5.5.2.1, para 5, first sentence: replace 'diagnosable' by
'diagnosed'.

United States

Set 1:

1.  WG14/N1089 is a good start on a rationale.  There should be one, either
included in the TR or in a separate document.

2.  The rationale should discuss why there are not _s versions of the
following functions, and the general philosophy involving minimizing
performance impact.

strchr, strcspn, strpbrk, strrchr, strspn, strstr

3.  The following functions are missing the specification that they open a
file for exclusive access.

tmpfile_s, fopen_s, freopen_s

4.  From the editor's report, it appears that sprintf_s and snprintf_s will
do essentially if not exactly the same thing.  Maybe only one of them is
needed.

5.  It would be best for the committee to spend some more time discussing
the notion of diagnosed undefined behavior.  This is a new invention for the
C standard.

##########

Set 2:

Page numbers refer to within the document, not the PDF page number.

Page v:  End of paragraph 6: Extra(?) "*".

Page 1: Should ISO/IEC 9899:1999/Cor 2:2004 be added to list of references?

Page 7+: Consider changing "bug" to "programming error".

Page 7: Footnote 9: Consider changing "constant expression" to "integer
constant expression".

Page 13: Paragraph 7 / Example 2: The end of that example says: "No
assignment to /s/ occurs.".  Where is that requirement in normative text?
Also, this seems like a large burden to place on the implementation
(requires a temporary buffer to hold the input string until that string's
length is known).  Better would be s[0] is set to a null character, and the
other elements of /s/ are unspecified.

Page 14/15: Footnote 13: Is on wrong page and overlays the section number.
Can the same footnote be referenced by three different sections (which are
on different pages)?

Page 16: 5.4.4.1p4: Consider adding: "and the other elements of /s/ are
unspecified".

Page 17: 5.5.1.1p2:  Consider adding: "maxsize == 0" to the list of
diagnosed undefined behavior.

Page 20: 5.5.2.2:  Why does qsort_s return void instead of errno_t?

How does it indicate failure?

Page 24: 5.6.1.2: End of paragraph 3: Extra(?) "*".

Page 28: 5.6.2.2p4: The 'm' in 'm+n' should be italic.

Page 31: 5.6.4.1p5: Why are there three '.' characters used to overwrite the
end of the string (Answer could go in a footnote)?

Would it be useful to show some examples both with and without the
overwrite?

Page 33: 5.7.2.1p2: Is the broken down time before or after the 1900 has
been added to it?  Why 0 rather than -999 (which fits in a 4 digit field)?

Page 37: 5.8.1.1: What happens if the string is longer than the space to
store it?  Is the first character set to null character?

Page 38: Footnote 28 extends too far down the page.

Pages 39-40:  Footnote 29 is referenced from two pages.

Page 46: 5.8.2.2.2p4: The 'm' in '-m+n' should be italic.

##########

Set 3:

1. The TR leaves it up to the implementation to determine the value

    of RSIZE_MAX.  The most useful value will often depend on both the

    implementation and the application, so many/most implementations

    will provide a way for an application to specify the value (at

    run-time).  On the other hand, some implementations may choose to

    make the value an unalterable translation-time constant.  We would

    like to see a specified means to set the value of RSIZE_MAX, with a

    status return indicating whether or not the value was successfully

    set.  One thought might be to do this through a function-like macro

    in stdint.h, e.g. "errno_t SET_RSIZE_MAX(size_t)".  An

    implementation that did not support an application's setting the

    value at run-time would not define the macro.  Otherwise, an

    invocation of the macro would return zero if the value was

    successfully set, or a non-zero value to indicate failure (e.g. an

    inappropriate value was specified or the application was built in a

    way to disallow run-time modification of the value).

2. The definition of diagnosed undefined behavior as calling an

    implementation defined function might benefit from examples of the

    name ans signature of such a function - not as a requirement, simply

    to encourage more than one implementation to make the same choices.

3. The memcpy_s function does not list overlap between input and output

    among its diagnosed undefined behaviors.  Is that solely because the

    language does not define pointer comparison between distinct

    objects, or is it considered a practical difficulty for real

    implementations?  In fact, the wording of "take on unspecified

    values", seems to preclude overlap from being diagnosed.  That's

    puzzling, as diagnosing memcpy calls that ought to be memmove calls

    is certainly a useful capability.

##########

Set 4:

1.  In some cases there seems to be change for the sake of it from what

     is either already standard or defacto standard.

     The common change seems to be return values that were char* with

     error being NULL being changed to this new errno_t type which is

     really just an int.

     strcpy_s        strlcpy

     strcat_s        strlcat

     asctime_s       asctime_r

     gtime_s         gtime_r

     localtime_s     localtime_r

2.  For many of the functions defined in this TR, it appears that very

     similar or identical alternatives are already available. In those

     cases, I'm not sure it makes sense to ignore prior art by defining

     new replacements. Some examples:

     A. tmpfile_s() is identical to the existing tmpfile() except for

        the style of returning the resulting FILE *.

     B. tmpnam_s() is almost the same as the existing tmpnam_r() except

        it includes an argument for the size of the destination buffer.

        More important, however, is the fact that it is still unsafe due

        to race conditions with others who might create the same files.

        Safe usage requires the use of tmpfile() or mkstemp() instead.

     C. strcpy_s() is equivalent to strlcpy(). It seems like providing

        yet another safe version of strcpy() would be confusing at

        best.

     D. fscanf_s() and related variants are just like the current

        routines except they require a size parameter for buffers that

        hold the result of %c, %s, and %[ formats. That's very useful,

        but I believe this feature could be added to the existing

        scanf() family in a compatible way. What's needed is a format

        modifier to indicate that the size is specified by a parameter,

        like the * in printf() format strings. Since scanf() already

        uses * for assignment suppression, a different character would

        be needed, but one could choose any unused format character and

        remain compatible with the existing scanf() functions.

3.  A comprehensive Rationale for the TR should be provided.

4.  The issues (including missing features) raised in the Secure TR

     Editor's Report, SC22 WG14 N1089, should be addressed.  N1089 is

     available at

      <http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1089.pdf>
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1089.pdf

5.  The committee should consider adding the following functions

     described in N1089:

     fprintf_s, printf_s, snprintf_s, sprintf, vfprintf_s, vprintf_s,

     vsnprintf_s, vsprintf_s, fwprintf_s, swprintf_s, vfwprintf_s,

     vwprintf_s, wprintf_s, vswprintf_s, mbstowcs_s, wcstombs_s,

     mbsrtowcs_s, wcsrtombs_s, wcrtomb_s

6.  The committee should consider adding support for optional

     truncation during string copy.  See  _TRUNCATE  in N1089.

7.  A footnote should be added explaining that the tmpfile_s, fopen_s,

     and freopen_s functions should open their files in a "safe" mode

     giving exclusive (non-shared) access.

8.  The committee should carefully consider the issues around

     "diagnosed undefined behavior," including:

   A.  the name of the term

   B.  the model of behavior

   C.  where the description of diagnosed undefined behavior should

       appear in a subclause specifying a function (in the

       "Description" section, in the "Returns" section, or in a new

       section labeled "Diagnosed Undefined Behavior").

 

Sally Seitz

Program Manager

ANSI

25 West 43rd Street

New York, NY 10036

Phone: (212) 642-4918

Fax: (212) 840-2298