Re: Privilege-escalation attacks on NT-based Windows are unfixable

From: David Thompson (david.thompson1@worldnet.att.net)
Date: 08/28/02


From: "David Thompson" <david.thompson1@worldnet.att.net>
Date: Wed, 28 Aug 2002 20:15:40 GMT

Alun Jones <alun@texis.com> wrote :
> In article <3D67D8A0.7060208@127.0.0.1>, Edward Elliott <nobody@127.0.0.1>
> wrote:
> >Alun Jones wrote:
> >> Are you really telling me that you wouldn't find, in thousands of software
> >> houses, code that read "inline void str_no_n_cpy(char *dest, const char
*src)
> >
> >> { while (*src) { *dest++=*src++; } *dest=0; }"?
> >
> >Yes that's my claim. Why bother writing a non-standard function when
> >you can just as easily use strncpy? strncpy(dst, src, dst_len) is best,
> >but I bet you'd also see strncpy(dst, src, strlen(dst)) and even
> >strncpy(dst, src, strlen(src)). The last two are slower but easier to
> >code. The last won't prevent buffer overflows, but if all three forms
> >were used with equal frequency, that'd be a 2/3 reduction in buffer
> >overflows as a result of strcpy.
>
> The last certainly won't prevent buffer overflows - in fact, it devolves to
> the same effect as the code example I posted - and the second-to-last is just
> plain wrong.
>
The middle (second-from-last or -from-first) is almost always wrong,
and sometimes, if the buffer didn't already contain a properly terminated
string, catastrophically unsafe. The third and last is NOT the same as
the code you posted (which IS the same as strcpy()) -- with those arguments
strncpy will always reach (and stop because of) the specified limit in which
case it does NOT write a null terminator, which means if you subsequently
use (read) that string you get at best wrong results and quite possibly a crash.

The first is safe in itself if dst_len is correct (which is sometimes difficult)
but again does not terminate the string if it hits the limit, and conversely
will pad out the whole buffer if the source is shorter than the limit, which
for a large buffer and on-average short data may be horrendously slow.

The comp.lang.c preferred (as in least disliked) approach is
  dst[0] = '\0'; strncat(dst, src, dst_size -1); /* or equivalent */

--
- David.Thompson 1 now at worldnet.att.net



Relevant Pages

  • Re: Privilege-escalation attacks on NT-based Windows are unfixable
    ... strncpy(dst, src, dst_len) is best, ... The last won't prevent buffer overflows, ... case it does NOT write a null terminator, ... use that string you get at best wrong results and quite possibly a crash. ...
    (comp.security.misc)
  • Re: gcc initialization better or extra line of execution
    ... As the buffer is provided by userspace to the kernel.We don't know if the buffer provided is null terminated or not. ... And if you're not using a fixed-length string literal in your real code, ... void populate_buffer; ... strncpy(ch, src, strlen(src) + 1); ...
    (comp.lang.c)
  • Re: A question about fprintf
    ... char *name, *buffer; ... FILE *src, *make; ... //now write the makefile. ...
    (comp.unix.programmer)
  • Re: replace substring
    ... that the buffer is big enough. ... void DoubleBackSlashes(char *src) ... char register *dst = src; ... This doesn't work when src points to a string literal. ...
    (comp.lang.c)
  • Re: replace substring
    ... that the buffer is big enough. ... void DoubleBackSlashes(char *src) ... char register *dst = src; ...
    (comp.lang.c)