Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] strcpy harmful, what?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date: Sat, 22 Oct 2005 00:10:15 +0200
On 10/21/05, Rich Coe <Richard.Coe@xxxxxxxxxx> wrote:
> I think that replacing strcpy with a library function that (eventually)
> calls strcpy (strncpy) a pointless, stupid exercise.
>
> It's slower and error prone.

Reading from what you say it appears to me that you might are not
aware of what a buffer overflow is. How they happen and why they are
to be avoided. So in order to explain you why we use g_strncpy we have
to explain the concepts of buffer overflow and malicious data.

An exploitable  buffer overflow happens whan the return pointer from a
funcion gets overwritten by stack data. This usually happens because
the program does not check the bounds of an array and a piece of code
keeps writing after the end of an array overwriting the return
pointer. If the return pointer gets overwritten the program instead of
returning to the caller will go and attempt to execute code wherever
the return pointer points.

Now given the fact that ethereal takes data from the network. And that
we cannot assume that a packet in the network is adequatelly formated.
We could find a packet that has a string that is not terminated by a
'\0', but someone might have added its "exploiting code" after it.

What would happen in that condition is that strcpy will keep copying
data until it doesn't find a '\0', way behind the buffer's bounds by
so overwriting  the return pointer in the stack and placing the
malicious code behind it. Then we might have a return pointer pointing
to the freshly added piece of code (the packet's payload).

Take a look at http://www.cultdeadcow.com/cDc_files/cDc-351/ for a
deeper explanation on how buffer overflows can be exploited.

AFAIK Impropperly used strcpy and strcat are the cause of most
exploitable buffer overflows!

So, back to the point: Using  g_sNprintf that is a function that
CHECKS BOUNDS is certainly less vulnerable than using a function that
does not check bounds. (fyi strcpy and strcat DO NOT CHECK BOUNDS).

Hope this time t was clear to you why we replace strcpy and strcat
(that DO NOT CHECK BOUNDS) with g_snprintf (that CHECKS BOUNDS).

Luis
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan