Re: Is it time for secure C ?

From: Arthur J. O'Dwyer (ajo_at_nospam.andrew.cmu.edu)
Date: 07/07/04 

Date: Wed, 7 Jul 2004 12:04:47 -0400 (EDT)

On Wed, 7 Jul 2004, Roman Ziak wrote:
>
> I just downloaded MS Visual Studio 2005 Express Beta. When I tried to
> compile existing valid project, I get a lot of warnings like 'sprintf'
> has been deprecated, 'strcpy' has been deprecated etc. I opened STDIO.H
> and figured that one has to define a macro _CRT_SECURE_NO_DEPRECATE
> to stop these warnings.

  (This sounds like typical Microsoft behavior. Ick.)

> I started to search internet and found few links, and the following
> proposal
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1031.pdf

  This is a somewhat interesting proposal, and one I hadn't seen
before (at least, not in such a standardese-specified way). It
doesn't strike me as particularly useful. Read on.

  The 'scanf_s' family of functions is slightly broken, from the
implementor's point of view. Consider Example 2 in section 3.2.2.1:

    EXAMPLE 2 The call:
      #define __USE_SECURE_LIB__
      #include <stdio.h>
      /* ... */
      int n; char s[5];
      n = fscanf_s(stdin, "%s", s, sizeof s);
    with the input line:
      hello
    will assign to 'n' the value 0 since a matching failure occurred
    because the sequence 'hello\0' requires an array of six characters
    to store it. No assignment to 's' occurs.

  In other words, the implementation of 'scanf_s' requires a lookahead
buffer of at least N characters, where N is some value specified by the
user at runtime. This is certainly possible (especially with C99 VLAs
at the implementor's disposal), but is the proposed "security" worth
the inconvenience?

  (There's also the issue of what happens when the programmer passes
a 'size_t' argument to a variadic function; I forget exactly what is
supposed to happen, but the integer promotions definitely don't help.
Maybe this is a non-issue in this case, though.)

  The 'gets_s' function is exactly equivalent to the existing 'fgets'
function, except that it discards the *USEFUL* end-of-line indicator,
which is the only thing that can tell the program that a full line
has indeed been read. 'gets_s' is thus *WORSE* than nothing! (Though
it's not as bad as 'gets'. ;)

  The 'rand_s' function would be absolutely a godsend... if the
author had bothered to specify its behavior!

  The 'bsearch_s' function is interesting, but of course it doesn't
add any functionality to the library that didn't already exist in C99
(I don't know whether C90 guaranteed that 'key' would always be the
first argument to 'compar'). And it has *nothing* to do with
security, so it's a little silly to attach it as a "rider" onto the
main proposal.

  The 'qsort_s' function is no better than the existing 'qsort'; it
guarantees neither O(NlgN) sorting time nor stable sorting. What
it *does* do is add unnecessary complexity; perhaps the 'context'
argument is an alternative to "locales" in C99? I don't know. It's
certainly not any improvement on the existing C99 functions.

  And from the security POV, the author completely forgot to address
the major security hole in both functions: they take two 'size_t'
parameters, right next to each other, and I never remember which
is which. The compiler is never smart enough to help, either. So
this is a potential source of major hard-to-find bugs in C programs,
and the proposed "secure" library doesn't even address the issue!

  'memcpy_s(foo, n, bar, n)' replaces the existing 'memcpy(foo, bar, n)',
and likewise 'memmove'. Extra verbosity, no security gain. Bad idea.

  In practice, 'strncpy_s' now performs exactly the same function as
'memcpy_s'; ironically, the historical extra security of filling the
array out with NUL bytes is removed!

  'strlen_s' is interesting, but I hardly think it's useful for its
intended purpose; after all, wasn't the whole point of this string
library proposal so that all strings *would* have well-defined lengths,
thus making the existing 'strlen' perfectly safe?

  In conclusion, I think it's pretty ironic that the proposal begins
with the paragraph

    Traditionally, the C Library has contained many functions that trust
    the programmer to provide output character arrays big enough to hold
    the result being produced. Not only do these functions not check that
    the arrays are big enough, they frequently lack the information needed
    to perform such checks. While it is possible to write safe, robust,
    and error-free code using the existing library, the library tends to
    promote programming styles that lead to mysterious failures if a
    result is too big for the provided array.

when all it does is provide even *more* functions that require "big
enough" character arrays with programmer-specified values, thus promoting
the "mysterious failure" programming style it claims to be trying to
avoid!

> Anyway, I am just wondering if anybody knows about the status of this
> proposal. And also would like to read some opinions.

  I hope this was useful to you.

-Arthur

Relevant Pages

  • Re: Prescott, was re: security coding guidelines for C/C++
    ... Part of the problem is simply the richness of a language syntax. ... First the application programmer must carefully ... for index My_Int'Range loop ... The second line defines an array type indexed by the type ...
    (comp.programming)
  • Re: Language design issues
    ... I'm not sure if it's better to make the programmer get the ... As I understand it a "towards" loop will not ... Maybe an array can tell you about its first and last index and you ...
    (comp.lang.misc)
  • Re: security enhacement to C runtime library (XXX_s)
    ... In the below link MS announces a security update to the C runtime ... Every buffer overflow error that was made before can still be ... strings in C the way they are used in every other programming ... how can we increase the programmer ...
    (comp.std.c)
  • Re: pid from startet process
    ... programmer expects. ... generate new candidates for PIDs by incrementing a counter. ... have not, however, yielded on the claim of a security threat posed ... the introduction of a system with randomized PIDs increased ...
    (comp.lang.perl.misc)
  • Re: [Full-Disclosure] Antigen Path Disclosure
    ... Im not a part of the security industry itself, im a programmer. ... But Still decided to uploaded 2 dodgey files and a jpg like he was ...
    (Full-Disclosure)