full-disclosure - Re: incorrect integer conversions in OpenSSL can result in memory corruption.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 21 Apr 2012 14:50:06 -0700
From: "Zach C." <fxchip@...il.com>
To: "noloader@...il.com" <noloader@...il.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>,
	Benjamin Kreuter <ben.kreuter@...il.com>
Subject: Re: incorrect integer conversions in OpenSSL can
	result in memory corruption.

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@...il.com> wrote:

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