Re: Stack growth direction to thwart buffer overflow attacks

From: Frank Cusack (fcusack_at_fcusack.com)
Date: 08/19/03


Date: Tue, 19 Aug 2003 06:38:26 -0700

On Tue, 19 Aug 2003 07:57:42 +0000 (UTC) phn@icke-reklam.ipsec.nu wrote:
> In comp.security.misc Frank Cusack <fcusack@fcusack.com> wrote:
>> On Sat, 16 Aug 2003 13:05:20 -0400 Tony Nelson <tonynlsn@shore.net> wrote:
>>> Surely not. I prefer to use:
>>>
>>> target[0] = 0;
>>> strncat(target,source,sizeof(target));
>>>
>>> strncat puts a NUL at the end of the string.
>
>> No, it doesn't. This is a prime example of what I think is a worse
>> problem than the wrong language (C), it's not understanding how to
>> use the API.
>
> Quoting from FreeBSD's manpage for strncat(3) :
...

FreeBSD is not the standard. Prior to C99, strn* implemenatations were
at the implementor's whim. Ahh ... that bit of info might shed some
light on why it stinks. C99 may have tried to accomodate the various
de facto implementations already in existence, rather than DTRT.

If you want to write correct programs, you cannot refer to vendor
documentation for standard libraries as your baseline. You have to
start with the standard docs (although H&S or K&R generally suffice)
and then make variations for each platform.

It just so happens that I am very aware of strn* problems. Many (most?)
aren't. You shouldn't have to be a friggin expert to be able to use
the language safely. With C, you do have to be an expert.

I'm sure you yourself are an experienced programmer. Only someone of
some reasonable level of knowledge would quote a manpage back to me.
And even you don't know how to use strn* correctly. See how hard it
is?

>> Why strn* were designed so poorly is another question.
>
> Maybe some reading will make this clear ?

Reading of what? C99 committee member's minds?

/fc



Relevant Pages

  • Re: So what Standard are we working off?
    ... continuing to improve the language. ... standard, the addition of "auto" alone seems to make the standard ... there are basically no C99 compilers and there is no demand from ... support), and 2) Non-determinable integer scalar sizes, that are not ...
    (comp.lang.c)
  • Re: Why the C committee doesnt provide an implementation when the standard is published?
    ... It is THE de-facto standard on the desktop. ... have pointed out recently the current crop of MS compilers are very good ... diverged one way whilst C went a different way 95 and C99. ... and quite a number of C99 language features. ...
    (comp.lang.c)
  • Re: So what Standard are we working off?
    ... But C99 basically addresses none of these problems over C89. ... problems with the C language: 1) No simple way to express a high-word ... with that "de facto standard". ... int8_t denotes a signed integer type with a width of exactly 8 bits. ...
    (comp.lang.c)
  • Re: Exceptions in C/C++
    ... C99 is proof that trying to evolve C is probably pointless. ... standard evolves, it won't be widely implemented enough to matter. ... You confuse this newsgroup and the C language. ...
    (comp.lang.c)
  • Re: Stack growth direction to thwart buffer overflow attacks
    ... >> problem than the wrong language, ... FreeBSD is not the standard. ... C99 may have tried to accomodate the various ... It just so happens that I am very aware of strn* problems. ...
    (comp.security.misc)