#2 mem* str* fns seg fault with negative 3rd arg

closed-fixed
nobody
None
5
2014-11-24
2004-04-09
Anonymous
No

From: tleek@ll.mit.edu
Subject: Fwd: [integer overflow problems with string.c &c]
Date: March 4, 2004 2:13:28 PM EST
To: hermantenbrugge@users.sourceforge.net
Cc: tjruwase@stanfordalumni.org

Hello. Enclosed is a bug report for gcc-cred (bounds checking
gcc). It is a very small fix for a very big problem --> memcpy,
strncpy, strncat, etc all break if you hand them a negative third
arg. Let me know if you need additional details!

Tim

Begin forwarded message:

From: Olatunji Ruwase <tjruwase@stanfordalumni.org>
Date: March 4, 2004 1:25:13 PM EST
To: Tim Leek <tleek@ll.mit.edu>
Subject: Re: [integer overflow problems with string.c &c]

Hi Tim,
You are aboslutely right, this is a real bug. Thanks for bringing it
to my
attention. Though I m still interested in the project, I m not the
maintainer.
Herman Ten Brugge (hermantenbrugge@users.sourceforge.net)
is the current maintainer on sourceforge and so is responsible for
bug fixes.
You can forward the bug report to him. I think your proffered
solution is
fine.
Thanks

tunji

Tim Leek <tleek@ll.mit.edu> wrote:

Tunji,

I'm not sure how active you are in continuing to develop gcc-cred.
Also not sure how much of this problem is your code or RWMJ. But
I
thought I'd make you aware of a problem with string.c which
contains
various wrappers for mem* and str* fns. You can tell me where to
stick
it if you like. Or perhaps you will direct me to the current
maintainer.

We have seen a fairly common vulnerability involving a call to
memcpy
or such in which the 3rd argument is a negative number. This is
apparently easy to do when that 3rd arg is computed incorrectly
sometimes. Consider the following tiny program.

#include<string.h>
int main() {
char x[10], y[10];
memcpy (x,y,-1);
}

I compiled this with gcc-cred and ran it. It seg faults. That is, the
bounds checking wrapper around memcpy is failing to trigger an
error
and instead is just calling the regular memcpy routine which fails.

Here's why. The -1 gets cast to an unsigned int, so really we have

memcpy (x,y,4294967295)

You'd think that in __bounds_check_memcpy (in string.c), one of
the
calls to "check" would catch the out of bounds read/write. Looks
like
erroneous ptr math is to blame here.

1. check (filename, line, dest, n, "memcpy", "destination pointer");
pointer=3221219168
size=4294967295
obj->extent = 3221219178
pointer+size=3221219167

Notice that pointer+size has wrapped around: (3221219168+
4294967295)
mod 4294967296 = 3221219167. The < test succeeds even though
pointer+size isout of proper range: it is one byte before the start
of
the dest.

2. check (filename, line, (void *) src, n, "memcpy", "source
pointer");
pointer=3221219216
size=4294967295
obj->extent = 3221219226
pointer+size=3221219215

Again, we wrap around and end up one byte before the beginning
of the
buffer.

I seem to be able to fix this by just adding a check to see if
pointer+size < pointer, which indicates an integer overflow.

I have attached the diff for string.c . Probably there are much
more
elegant solutions...

Tim

[tleek@swann lib]$ diff string.c
/data/ia/tools/gcc-cred/gcc-3.3.2/gcc/bounds/lib/string.c
134d133
<
140,147d138
<
< if ((char *) pointer + size < (char *) pointer)
< __bounds_errorf (filename, line, pointer, obj,
< "%s with this %s and size %u would overrun"
< " the end of the object's allocated memory"
< " because of an integer overflow",
< function, ptr_name, size);
<
175d165
<
235d224
<
249,250d237
<
<

-----------------------

Tim Leek, Technical Staff,
Group 62, MIT / Lincoln Lab
244 Wood Street,
Lexington, MA 02420-9108
room: S4-131, email: tleek@ll.mit.edu
phone: 781-981-2975, fax: 781-981-0186

When I see an adult on a bicycle, I do not despair for the future of
the human race. - H. G.Wells

________________________________________________________
____________

-----------------------

Tim Leek, Technical Staff,
Group 62, MIT / Lincoln Lab
244 Wood Street,
Lexington, MA 02420-9108
room: S4-131, email: tleek@ll.mit.edu
phone: 781-981-2975, fax: 781-981-0186

When I see an adult on a bicycle, I do not despair for the future of
the human race. - H. G.Wells

Discussion

  • Herman ten Brugge

    Logged In: YES
    user_id=844843

    This will be solved in the upcomming 3.4.2 release. Sorry
    that I missed this one when generating 3.3.4 and 3.4.0 and
    3.4.1 patches.

     
  • Herman ten Brugge

    • status: open --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks