using static char arrays to be on the safe side

[rep_movsd]

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

[pete]

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

[Eric Sosman]

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 passwordVerifie d' variable without providing
the password?

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

Define "exploit."

--
Eric Sosman
es*****@ieee-dot-org.invalid

[JimS]

On Sat, 17 Nov 2007 08:27:10 -0800 (PST), rep_movsd
<re*******@gmai l.comwrote:

>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...ma ny others.

Jim

[Malcolm McLean]

"rep_movsd" <re*******@gmai l.comwrote 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

[christian.bau]

On Nov 17, 4:27 pm, rep_movsd <rep.mo...@gmai l.comwrote:

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.

[rep_movsd]

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

[santosh]

In article
<79************ *************** *******@w28g200 0hsf.googlegrou ps.com>,
rep_movsd <re*******@gmai l.comwrote 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.

[CBFalconer]

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....

Incomprehensibl e. See the advice in my sig, below.

--
If you want to post a followup via groups.google.c om, 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

[rep_movsd]

On Nov 20, 3:52 am, CBFalconer <cbfalco...@yah oo.comwrote:

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....

Incomprehensibl e. See the advice in my sig, below.

--
If you want to post a followup via groups.google.c om, 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.co m

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.c om/group/comp.lang.c/browse_thread/thread/
073b39de9430aec 9#

Vivek