* cluts memcpy() test @ 2011-07-20 0:28 Solar Designer 2011-07-20 10:30 ` Luka M. 0 siblings, 1 reply; 3+ messages in thread From: Solar Designer @ 2011-07-20 0:28 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: cluts memcpy() test 2011-07-20 0:28 cluts memcpy() test Solar Designer @ 2011-07-20 10:30 ` Luka M. 2011-07-20 13:27 ` Rich Felker 0 siblings, 1 reply; 3+ messages in thread From: Luka M. @ 2011-07-20 10:30 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: cluts memcpy() test 2011-07-20 10:30 ` Luka M. @ 2011-07-20 13:27 ` Rich Felker 0 siblings, 0 replies; 3+ messages in thread From: Rich Felker @ 2011-07-20 13:27 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-07-20 13:27 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-07-20 0:28 cluts memcpy() test Solar Designer 2011-07-20 10:30 ` Luka M. 2011-07-20 13:27 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).