Re: Stack growth direction to thwart buffer overflow attacks

From: Ken Hagan (K.Hagan_at_thermoteknix.co.uk)
Date: 08/14/03

  • Next message: Nick Maclaren: "Re: Stack growth direction to thwart buffer overflow attacks" 
    Date: Thu, 14 Aug 2003 09:54:01 +0100

    Douglas Siebert wrote:
    >
    > I'd
    > like to see it create hidden internal variables attached to every
    > array whether global, automatic or created via malloc() that are
    > checked
    > when writing to that string, calls to e.g., sprintf and strcpy
    > replaced
    > with calls to snprintf and strncpy, including appropriate termination
    > via SIGABRT or whatever when the buffer is exceeded, etc.

    I don't think we need run-time support for this.

    Simply removing sprintf, strcpy and friends from the headers allows
    the compile time detection of *these* cases. The resulting compiler
    errors are either trivial to fix or something that shouldn't be let
    out of the door. (Why? Well, either you know size of the target
    buffer, in which case that's what you write for the extra parameter,
    or you don't in which case how do you know it won't overflow?)

    Alternatively, the MS compiler has an extension that lets you mark
    some functions as "deprecated". Deprecated functions generate a
    warning which means the legacy code base still builds, but managers
    can insist that the warning count falls over time. Since they've
    added the feature to their own compiler, one presumes that MS are
    already doing this.

    For the wider problem of running off the ends of an array, PC-LINT
    has an option that attempts to track buffer sizes and validate
    pointer dereferences. (For problems where the array sizes are
    actually available, it seems to work quite well in my experience.)
    It is presumably trivial to generate a warning for the case where
    that tracking cannot be done. Such warnings would direct managers
    to precisely those areas of the system that couldn't be proven to
    be free of overflows. Over time, they can insist that these are
    dealt with.

    I think the honest truth is that buffer overflows can be all but
    eliminated from real life C and C++ programs but that we haven't
    been hit by enough worms yet.

  • Next message: Nick Maclaren: "Re: Stack growth direction to thwart buffer overflow attacks"

    Relevant Pages

    • Re: Stack growth direction to thwart buffer overflow attacks
      ... > via SIGABRT or whatever when the buffer is exceeded, ... the MS compiler has an extension that lets you mark ... can insist that the warning count falls over time. ... For the wider problem of running off the ends of an array, ...
      (comp.security.misc)
    • Re: PR-Tree
      ... defines main to return an int. ... Not void, not string, not array of doubles. ... buffer, though I suspect the getch- also not part of C - might do that. ... and Turboc compiler or any windows compatible c language compiler) ...
      (comp.lang.c)
    • Re: array of lists
      ... That is a measure of last resort. ... If the compiler is making a noise, ... create an array WITH a generic type then it ... A warning is exactly that, ...
      (comp.lang.java.programmer)
    • Re: arrays as function arguments
      ... why doesn't calling f1 cause a warning while calling f2 ... In case of 'f1' there's no reason for the compiler to warn if the actual array size is different from the "fictive" size specified in the argument declarator, and there's no way to make it watch for array sizes in this case. ...
      (comp.lang.c)
    • Re: Missing Index Value in Array Aggregate
      ... was the initial value of a constant array object, ... me the warning of a constraint error at run time. ... compiler tends to put out a bunch of warnings of much ...
      (comp.lang.ada)
    • Quantcast