cluts memcpy() test

cluts memcpy() test

[Solar Designer]

Luka, Rich -

It'd be nice for cluts to detect issues like this:

http://www.nodefense.org/eglibc.txt

Maybe it already does?

"... an attacker controllable length value is used to calculate the jump
table pointer index in the optimized copy function. Setting the length
value to a negative number will cause a jmp instruction to be skipped
due to an signedness vulnerbility, resulting in attacker supplied value
being used to calculate the location of a jump table function, resulting
in malicious code execution."

Alexander

Re: cluts memcpy() test

[Luka M.]

[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

On Wed, Jul 20, 2011 at 2:28 AM, Solar Designer <solar@openwall.com> wrote:

> Luka, Rich -
>
> It'd be nice for cluts to detect issues like this:
>
> http://www.nodefense.org/eglibc.txt
>
> Maybe it already does?
>

Hey Alexander. Cluts doesn't test negative values for memcpy. Such a thing
hasn't occured to me: The prototype for the function specifies a size_t
argument, and size_t is supposed to be unsigned. This means, _afaik_, that a
negative value should be implicitly cast to a positive "equivalent". So, I
assume testing for this would be only useful as a way to show that (one of)
eglibc's implementation(s) doesn't obey sheer basics. However (not that this
isn't an eerie bug), I'm also a bit skeptical as to how a user-provided
value [+not stored in a size_t] would find itself in an argument to memcpy.
String.c is next after the alloc.c rewrite which is what I'm doing now (and
possibly after the task #7 which you suggested a while back), so if Rich
thinks this may be important to test for a reason unobvious to me, I guess I
can throw it in (though I'd have to use some non-size_t, sufficiently big
signed type to store test data :-/). In case of eglibc, I could have memcpy
jump to the same function used as the signal handler, and then it'd jump
back to a setjmp and we'd notice this behavior (that is, assuming the size
of the real argument type can be callculated for each platform). If I then
use the same setjmp/handler for a SIGSEGV, we could also catch other
hypothetical and only similarily buggy implementation behavior, and have
both report a same ambigous "negative argument" error message. But then I
guess the same applies to all other functions that should take a size_t or
any other positive type, doesn't it? :-/
Luka.

[-- Attachment #2: Type: text/html, Size: 2179 bytes --]

Re: cluts memcpy() test

[Rich Felker]

On Wed, Jul 20, 2011 at 12:30:35PM +0200, Luka M. wrote:
> On Wed, Jul 20, 2011 at 2:28 AM, Solar Designer <solar@openwall.com> wrote:
> 
> > Luka, Rich -
> >
> > It'd be nice for cluts to detect issues like this:
> >
> > http://www.nodefense.org/eglibc.txt
> >
> > Maybe it already does?
> >
> 
> Hey Alexander. Cluts doesn't test negative values for memcpy. Such a thing
> hasn't occured to me: The prototype for the function specifies a size_t
> argument, and size_t is supposed to be unsigned. This means, _afaik_, that a
> negative value should be implicitly cast to a positive "equivalent". So, I

The problem is (or rather was; I assume it's fixed now) broken asm in
glibc that treated the unsigned value as if it were signed...

Note that musl will not allow you to allocate memory so large that the
unsigned size would be negative if interpreted as a signed value,
since that would create dangerous situations where ptrdiff_t
overflows. It may still be possible to make a region that large
explicitly using mmap, however.

Rich