using static char arrays to be on the safe side

Discussion in 'C Programming' started by rep_movsd, Nov 17, 2007.

  1. rep_movsd

    rep_movsd Guest

    Hi

    I program primarily in C++ , but once in a while one is forced to use
    the odd strcpy or call API functions that dump results into char*
    buffers.

    I believe that most security exploits that work by thrashing the stack
    to overwrite the return address, allowing arbitrary code execution.
    I have now fallen into the habit of declaring temporary buffers as
    static char arrays.

    Is this a good idea in general?

    Are there other kinds of exploits which do not rely on stack
    thrashing?


    Vivek
    rep_movsd, Nov 17, 2007
    #1
    1. Advertising

  2. rep_movsd

    pete Guest

    rep_movsd wrote:
    >
    > Hi
    >
    > I program primarily in C++ , but once in a while one is forced to use
    > the odd strcpy or call API functions that dump results into char*
    > buffers.
    >
    > I believe that most security exploits that work by thrashing the stack
    > to overwrite the return address, allowing arbitrary code execution.
    > I have now fallen into the habit of declaring temporary buffers as
    > static char arrays.
    >
    > Is this a good idea in general?


    No.
    Either your program is correct or it isn't.

    --
    pete
    pete, Nov 17, 2007
    #2
    1. Advertising

  3. rep_movsd

    Eric Sosman Guest

    rep_movsd wrote:
    > Hi
    >
    > I program primarily in C++ , but once in a while one is forced to use
    > the odd strcpy or call API functions that dump results into char*
    > buffers.
    >
    > I believe that most security exploits that work by thrashing the stack
    > to overwrite the return address, allowing arbitrary code execution.
    > I have now fallen into the habit of declaring temporary buffers as
    > static char arrays.
    >
    > Is this a good idea in general?


    No. Just for starters, it becomes extremely difficult
    to write a re-entrant function. Also, it doesn't solve the
    real problem, which is overrunning the array boundaries to
    begin with. You'll probably trash a different chunk of
    memory by running off the end of a static array than you
    would if the array were auto or dynamic, but what makes you
    think the trashed stuff is any less important, or that its
    trashing is less of a threat? If the bad guy can overwrite
    a function pointer variable, for example, that's about as
    good as diddling a return address. Or what if he manages
    to set the `bool passwordVerified' variable without providing
    the password?

    > Are there other kinds of exploits which do not rely on stack
    > thrashing?


    Define "exploit."

    --
    Eric Sosman
    lid
    Eric Sosman, Nov 17, 2007
    #3
  4. rep_movsd

    JimS Guest

    On Sat, 17 Nov 2007 08:27:10 -0800 (PST), rep_movsd
    <> wrote:

    >Hi
    >
    >I program primarily in C++ , but once in a while one is forced to use
    >the odd strcpy or call API functions that dump results into char*
    >buffers.
    >
    >I believe that most security exploits that work by thrashing the stack
    >to overwrite the return address, allowing arbitrary code execution.
    >I have now fallen into the habit of declaring temporary buffers as
    >static char arrays.
    >
    >Is this a good idea in general?
    >
    >Are there other kinds of exploits which do not rely on stack
    >thrashing?


    Integer overflow, memory allocator, %n print format specifier,
    overwriting static data structures...many others.

    Jim
    JimS, Nov 17, 2007
    #4
  5. "rep_movsd" <> wrote in message
    > I program primarily in C++ , but once in a while one is forced to use
    > the odd strcpy or call API functions that dump results into char*
    > buffers.
    >
    > I believe that most security exploits that work by thrashing the stack
    > to overwrite the return address, allowing arbitrary code execution.
    > I have now fallen into the habit of declaring temporary buffers as
    > static char arrays.
    >
    > Is this a good idea in general?
    >
    > Are there other kinds of exploits which do not rely on stack
    > thrashing?
    >

    The word is "trashing". Thrashing the stack means something quite different.

    As Pete said, either your code is correct or it isn't. Whilst static arrays
    may provide some protection from exploits, it's very partial - if you
    overwrite another global you might also create a security hole, certainly
    bugs will be harder to trace than if you corrupt the stack return address
    with a random value, which can to all intents and purposes be guaranteed to
    produce a crash.

    It is not really easy to anwer the question "should I have an extra layer of
    protection?". It creates costs elsewhere, for instance making code
    non-rentrant. Because after the first call the static will be initialised to
    a "sensible" value, it might also make any errors worse. Also, another
    programmer would wonder why the value needs to be preserved across function
    calls. However ultimately it is very difficult to say whether these outweigh
    lose that one last final defence to a buffer exploit attack.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Nov 17, 2007
    #5
  6. On Nov 17, 4:27 pm, rep_movsd <> wrote:
    > Hi
    >
    > I program primarily in C++ , but once in a while one is forced to use
    > the odd strcpy or call API functions that dump results into char*
    > buffers.
    >
    > I believe that most security exploits that work by thrashing the stack
    > to overwrite the return address, allowing arbitrary code execution.
    > I have now fallen into the habit of declaring temporary buffers as
    > static char arrays.
    >
    > Is this a good idea in general?


    It is an awful idea. Any buffer overflows will now overwrite random
    bits of global memory, in practice overwriting random other static or
    global variables, with all kinds of possible consequences. Furthermore
    you make it impossible to use any of your code in a multi-threaded
    environment.
    christian.bau, Nov 17, 2007
    #6
  7. rep_movsd

    rep_movsd Guest

    Oh well, I guess its best to avoid such "fixes" and make sure I always
    know the size of the data that I strcpy or memcpy, in any case most
    APIs ( at least WIN32 ones that i know of ) can be made to return the
    size of the data that they will return....

    Vivek
    rep_movsd, Nov 19, 2007
    #7
  8. rep_movsd

    santosh Guest

    In article
    <>,
    rep_movsd <> wrote on Monday 19 Nov 2007 2:12 pm:

    > Oh well, I guess its best to avoid such "fixes" and make sure I always
    > know the size of the data that I strcpy or memcpy, in any case most
    > APIs ( at least WIN32 ones that i know of ) can be made to return the
    > size of the data that they will return....


    At one level or another size and other information _has_ to be
    maintained and respected, for things to work. The C language exposes
    more of these "details" to the programmer than many other, more recent,
    languages. This has both benefits and drawbacks.
    santosh, Nov 19, 2007
    #8
  9. rep_movsd

    CBFalconer Guest

    rep_movsd wrote:
    >
    > Oh well, I guess its best to avoid such "fixes" and make sure I
    > always know the size of the data that I strcpy or memcpy, in any
    > case most APIs ( at least WIN32 ones that i know of ) can be made
    > to return the size of the data that they will return....


    Incomprehensible. See the advice in my sig, below.

    --
    If you want to post a followup via groups.google.com, ensure
    you quote enough for the article to make sense. Google is only
    an interface to Usenet; it's not Usenet itself. Don't assume
    your readers can, or ever will, see any previous articles.
    More details at: <http://cfaj.freeshell.org/google/>



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Nov 20, 2007
    #9
  10. rep_movsd

    rep_movsd Guest

    On Nov 20, 3:52 am, CBFalconer <> wrote:
    > rep_movsd wrote:
    >
    > > Oh well, I guess its best to avoid such "fixes" and make sure I
    > > always know the size of the data that I strcpy or memcpy, in any
    > > case most APIs ( at least WIN32 ones that i know of ) can be made
    > > to return the size of the data that they will return....

    >
    > Incomprehensible. See the advice in my sig, below.
    >
    > --
    > If you want to post a followup via groups.google.com, ensure
    > you quote enough for the article to make sense. Google is only
    > an interface to Usenet; it's not Usenet itself. Don't assume
    > your readers can, or ever will, see any previous articles.
    > More details at: <http://cfaj.freeshell.org/google/>
    >
    > --
    > Posted via a free Usenet account fromhttp://www.teranews.com


    Sorry, here is my original query and google groups thread link

    rep_movsd wrote:

    > Hi


    > I program primarily in C++ , but once in a while one is forced to use
    > the odd strcpy or call API functions that dump results into char*
    > buffers.


    > I believe that most security exploits that work by thrashing the stack
    > to overwrite the return address, allowing arbitrary code execution.
    > I have now fallen into the habit of declaring temporary buffers as
    > static char arrays.


    > Is this a good idea in general?


    Followed up on
    groups.google.com/group/comp.lang.c/browse_thread/thread/
    073b39de9430aec9#

    Vivek
    rep_movsd, Nov 23, 2007
    #10
  11. rep_movsd

    Richard Guest

    rep_movsd <> writes:

    > On Nov 20, 3:52 am, CBFalconer <> wrote:
    >> rep_movsd wrote:
    >>
    >> > Oh well, I guess its best to avoid such "fixes" and make sure I
    >> > always know the size of the data that I strcpy or memcpy, in any
    >> > case most APIs ( at least WIN32 ones that i know of ) can be made
    >> > to return the size of the data that they will return....

    >>
    >> Incomprehensible. See the advice in my sig, below.
    >>
    >> --
    >> If you want to post a followup via groups.google.com, ensure
    >> you quote enough for the article to make sense. Google is only
    >> an interface to Usenet; it's not Usenet itself. Don't assume
    >> your readers can, or ever will, see any previous articles.
    >> More details at: <http://cfaj.freeshell.org/google/>
    >>
    >> --
    >> Posted via a free Usenet account fromhttp://www.teranews.com

    >
    > Sorry, here is my original query and google groups thread link


    Oh dear. Prepare for more of his signature advice because you forgot to
    snip his double signature.

    >
    > rep_movsd wrote:
    >
    >> Hi

    >
    >> I program primarily in C++ , but once in a while one is forced to use
    >> the odd strcpy or call API functions that dump results into char*
    >> buffers.

    >
    >> I believe that most security exploits that work by thrashing the stack
    >> to overwrite the return address, allowing arbitrary code execution.
    >> I have now fallen into the habit of declaring temporary buffers as
    >> static char arrays.

    >
    >> Is this a good idea in general?

    >
    > Followed up on
    > groups.google.com/group/comp.lang.c/browse_thread/thread/
    > 073b39de9430aec9#
    >
    > Vivek
    Richard, Nov 23, 2007
    #11
  12. Richard wrote:
    [21 lines deleted]
    >
    > Oh dear. Prepare for more of his signature advice because you forgot to
    > snip his double signature.
    >

    [16 lines deleted]

    Richard, did you really need to quote the entire article to say that?
    (Hint: No, you didn't.) (Hint: This criticism is from someone with
    a valid signature; perhaps you'll pay attention to it.)

    Are you incapable of trimming quoted text?

    You said recently that you had killfiled CBFalconer. I had hoped
    this would mean we wouldn't see any more complaints from you about
    his signature(s).

    --
    Keith Thompson (The_Other_Keith) <>
    Looking for software development work in the San Diego area.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Nov 23, 2007
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Fred
    Replies:
    2
    Views:
    1,069
    Craig Deelsnyder
    Jul 12, 2004
  2. Bill Reyn
    Replies:
    3
    Views:
    2,248
    Bob Hairgrove
    Jun 22, 2004
  3. lovecreatesbeauty
    Replies:
    1
    Views:
    1,034
    Ian Collins
    May 9, 2006
  4. arnuld
    Replies:
    19
    Views:
    688
    Jacek Dziedzic
    Mar 30, 2007
  5. Philipp
    Replies:
    21
    Views:
    1,123
    Philipp
    Jan 20, 2009
Loading...

Share This Page