Re: [Lit.] Buffer overruns
From: Douglas A. Gwyn (DAGwyn_at_null.net)
Date: 12/09/04
- Next message: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Previous message: Bryan Olson: "Re: Randomness from data"
- In reply to: Anne & Lynn Wheeler: "Re: [Lit.] Buffer overruns"
- Next in thread: David Wagner: "Re: [Lit.] Buffer overruns"
- Reply: David Wagner: "Re: [Lit.] Buffer overruns"
- Reply: Anne & Lynn Wheeler: "Re: [Lit.] Buffer overruns"
- Reply: Bryan Olson: "Re: [Lit.] Buffer overruns"
- Reply: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 08 Dec 2004 22:44:40 -0500
There are advantages and disadvantages to all the
plausible designs for handling character strings
and arbitrary data buffers. (For example, counted
strings have more space overhead than terminated
strings, an upper limit to length, and no sharing
of constant identical tails (unless even more
space and time overhead is added).) In C, you get
to choose the design you use, which might match an
existing design or be custom-tailored as you see
fit; nobody is forcing you to use a pre-existing
set of library functions if it happens not to be
appropriate for the task at hand. You can use
that freedom to duplicate any of the facilities
that you have described as more suitable; with C++
you can also use more convenient operator syntax
than is available with C.
There is also an important point that this whole
line of discussion keeps missing, namely: if the
programmer's assumptions are violated at run time,
something *unplanned* is going to happen, which is
bad from the security perspective. That is as true
with boundary-enforced buffer mechanisms as it is
for the sloppy UCB undergraduate hacks that so many
systems "borrowed" for their IP suite. At the very
least, you have a DoS vulnerabililty, but it could
be a lot worse -- since the program will execute
some "error" code that the programmer did not mean
to be executed. Imagine a medical control device
or an automotive or flight control device that
traps to a stack-trace abort when a boundary is
violated.
- Next message: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Previous message: Bryan Olson: "Re: Randomness from data"
- In reply to: Anne & Lynn Wheeler: "Re: [Lit.] Buffer overruns"
- Next in thread: David Wagner: "Re: [Lit.] Buffer overruns"
- Reply: David Wagner: "Re: [Lit.] Buffer overruns"
- Reply: Anne & Lynn Wheeler: "Re: [Lit.] Buffer overruns"
- Reply: Bryan Olson: "Re: [Lit.] Buffer overruns"
- Reply: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|