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

["Zach C." <fxchip () gmail com>]

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 () gmail com> wrote:

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