Re: [Full-disclosure] incorrect integer conversions in OpenSSL can result in memory corruption.

["Zach C." <fxchip@xxxxxxxxx>]

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 <noloader@xxxxxxxxx> wrote:

> On Thu, Apr 19, 2012 at 10:32 AM, Benjamin Kreuter
> <ben.kreuter@xxxxxxxxx> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>> 
>> On Thu, 19 Apr 2012 12:35:22 +0200
>> Tavis Ormandy <taviso@xxxxxxxxxxxxx> 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/