Re: Secure C library

daw@xxxxxxxxxxxxxxxxxxxxxxxx (David Wagner) wrote:

> Richard Bos wrote:
> >The obvious solution is to add a new set of functions, *printf_very_s(),
> >where it is a constraint violation if the format parameter is not either
> >a constant or a const-specified variable.
>
> Requiring the format string parameter to be const-specified doesn't
> prevent format string vulnerabilities.
>
> Requiring the format string parameter to be a constant string is
> arguably too strict.

I am aware of both of these. My point was - perhaps expressed too subtly
- that adding repeated slightly safer versions of *printf(), while not
addressing either the glaring holes in *scanf() or in the programmer, is
the wrong way to go about making C safer.


To put it more clearly:

The current proposal removes the %n specifier from printf(), because
that could, very much in theory, introduce a rather obvious bug where it
is led to write through a wild pointer, and not to write to the expected
place. Under normal circumstances, though, this specifier can be a very
useful tool to write _safer_ programs, by giving the programmer
information about how much text he has already written.

On the other hand, this proposal adds a replacement function for gets(),
which can be simply written using the existing fgets(). Superfluous,
really. What's worse, the proposal does not remove gets(), which is
fundamentally broken and cannot be used safely without the employ of
bondage gear and padlocks.
(In my previous post I wrote that it does nothing to prevent unsafe use
of the *scanf() family, but I see now that I overlooked the relevant
clause: it does.).

In other words, n1135 addresses a small, theoretical hole, at the
expense of a useful and safety-enhancing feature, while not helping
enough with the largest hole in C's safety. The greatest problems with
buffer overruns do not occur on output, but on input (as evidenced by,
oh, just about every second M$ exploit and IIRC also the Great Worm);
and this proposal concerns itself with exactly the wrong side of I/O.


Finally, this proposal, and most others like it, preach to the choir.
The programmers who will read and apply it are those who are already
aware of the need for safety. These are not the greatest problem. The
programmer who _does_ need this proposal, because he is the kind of hack
who cannot write safe code using existing C, is precisely the programmer
who will ignore any such proposal, either because he thinks it will
"restrict him in his freedom", because he (thinks he) needs the raw
power of straight C, or because he isn't even aware of its existence.

If we want safer programs, we shouldn't be working on making the next
generation C somewhat safer at the cost of efficiency. We should be
working on making the next generation C _programmers_ much safer.

Richard
.

Relevant Pages

  • Re: choice of character for relational division
    ... because the format is so regular. ... system's own tables which were accessible to any programmer, ... level and declarative, or low level and procedural, our code ... If the source unit is small enough, one comment suffices, which means one comment table suffices. ...
    (comp.databases.theory)
  • Re: choice of character for relational division
    ... because the format is so regular. ... "Source code checks in but it doesn't check out!") ... system's own tables which were accessible to any programmer, ... level and declarative, or low level and procedural, our code ...
    (comp.databases.theory)
  • Re: floating point arithmetic problems
    ... Programmer people who don't pay ... The VCL could never supply a single set of functions to handle both ... presentation format is designated "default" ... the storage format to be geared towards humans at all. ...
    (comp.lang.pascal.delphi.misc)
  • Re: [Lit.] Buffer overruns
    ... >> some features of the safer PLs in comparison to C. ... >> raw machine coding. ... those checking features of a safer PL that are ... being detected -- on the assumption that the programmer ...
    (sci.crypt)
  • Re: [Lit.] Buffer overruns
    ... >>Now a safer ... >>the programmer, if he wants to). ... Some of the code review is automated (this ... > is reduced by maximal use of libraries. ...
    (sci.crypt)
Loading