Well, not cleanly... I would think though that a signed integer cast to a size_t would have unpredictable results (but mostly just a larger value than intended...). At least when size_t and int are both 32bit. Or am I wrong?
On Apr 21, 2012, at 2:33 PM, Jeffrey Walton <[email protected]> wrote: > On Thu, Apr 19, 2012 at 10:32 AM, Benjamin Kreuter > <[email protected]> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On Thu, 19 Apr 2012 12:35:22 +0200 >> Tavis Ormandy <[email protected]> wrote: >> >>> All versions of OpenSSL on all platforms up to and including version >>> 1.0.1 are affected. >> >> [snip] >> >>> BUF_MEM_grow_clean accepts a size_t, but the subroutine it uses to >>> handle the allocation only accepts a 32bit signed integer. >> >> Correct me if I am wrong, but shouldn't this only be a problem on >> systems where a size_t is wider than an int i.e. not on 32 bit systems? > I don't believe so (that is, it can be a problem on 32 bit systems), > but I'd need to see more context. For example, if the attacker > controls the size and forces the size to negative (due to use of an > int), then it will never convert to a size_t. > > void *CRYPTO_realloc_clean(void *str, int old_len, int num, const char > *file, int line) > { > /* ... */ > ret=malloc_ex_func(num,file,line); > if(ret) > { > memcpy(ret,str,old_len); > OPENSSL_cleanse(str,old_len); > free_func(str); > } > /* ... */ > return ret; > } > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
