Exploit-DB #18756
Description: OpenSSL - ASN1 BIO Memory Corruption
Type: dos
Platform: multiple
Date: 2012-04-19
Author: Tavis Ormandy

Exploit:
Incorrect integer conversions in OpenSSL can result in memory corruption.
--------------------------------------------------------------------------

CVE-2012-2110

This advisory is intended for system administrators and developers exposing
OpenSSL in production systems to untrusted data.

asn1_d2i_read_bio in OpenSSL contains multiple integer errors that can cause
memory corruption when parsing encoded ASN.1 data. This error can be exploited
on systems that parse untrusted data, such as X.509 certificates or RSA public
keys.

The following context structure from asn1.h is used to record the current state
of the decoder:

typedef struct asn1_const_ctx_st
{
    const unsigned char *p;/* work char pointer */
    int eos;    /* end of sequence read for indefinite encoding */
    int error;  /* error code to use when returning an error */
    int inf;    /* constructed if 0x20, indefinite is 0x21 */
    int tag;    /* tag from last 'get object' */
    int xclass; /* class from last 'get object' */
    long slen;  /* length of last 'get object' */
    const unsigned char *max; /* largest value of p allowed */
    const unsigned char *q;/* temporary variable */
    const unsigned char **pp;/* variable */
    int line;   /* used in error processing */
} ASN1_const_CTX;

These members are populated via calls to ASN1_get_object and asn1_get_length
which have the following prototypes

int ASN1_get_object(const unsigned char **pp,
                    long *plength,
                    int *ptag,
                    int *pclass,
                    long omax);

int asn1_get_length(const unsigned char **pp,
                    int *inf,
                    long *rl,
                    int max);

The lengths are always stored as signed longs, however, asn1_d2i_read_bio
casts ASN1_const_CTX->slen to a signed int in multiple locations. This
truncation can result in numerous conversion problems.

The most visible example on x64 is this cast incorrectly interpreting the
result of asn1_get_length.

222             /* suck in c.slen bytes of data */
223             want=(int)c.slen;

A simple way to demonstrate this is to prepare a DER certificate that contains
a length with the 31st bit set, like so

$ dumpasn1 testcase.crt
0 NDEF: [PRIVATE 3] {
   2[PII_REDACTED]:   [1]
        ...
   }

Breakpoint 2, asn1_d2i_read_bio (in=0x9173a0, pb=0x7fffffffd8f0) at a_d2i_fp.c:224
224             if (want > (len-off))
(gdb) list
219             }
220         else
221             {
222             /* suck in c.slen bytes of data */
223             want=(int)c.slen;
224             if (want > (len-off))
225                 {
226                 want-=(len-off);
227                 if (!BUF_MEM_grow_clean(b,len+want))
228                     {
(gdb) p c.slen
$18 =[PII_REDACTED]
(gdb) p want
$19 = [PII_REDACTED]

This results in an inconsistent state, and will lead to memory corruption.

--------------------
Affected Software
------------------------

All versions of OpenSSL on all platforms up to and including version 1.0.1 are
affected.

Some attack vectors require an I32LP64 architecture, others do not.

--------------------
Consequences
-----------------------

In order to explore the subtle problems caused by this, an unrelated bug in the
OpenSSL allocator wrappers must be discussed.

It is generally expected that the realloc standard library routine should support
reducing the size of a buffer, as well as increasing it. As ISO C99 states "The
realloc function deallocates the old object pointed to by ptr and returns a
pointer to a new object that has the size speciﬁed by size. The contents of the
new object shall be the same as that of the old object prior to deallocation,
up to the lesser of the new and old sizes."

However, the wrapper routines from OpenSSL do not support shrinking a buffer,
due to this code:

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;
}

The old data is always copied over, regardless of whether the new size will be
enough. This allows us to turn this truncation into what is effectively:

    memcpy(heap_buffer, <attacker controlled buffer>, <attacker controlled size>);

We can reach this code by simply causing an integer to be sign extended and
truncated multiple times. These two protoypes are relevant:

int BUF_MEM_grow_clean(BUF_MEM *str, size_t len);

void *CRYPTO_realloc_clean(void *str, int old_len, int num, const char *file, int line);

BUF_MEM_grow_clean accepts a size_t, but the subroutine it uses to handle the
allocation only accepts a 32bit signed integer. We can exploit this by
providing a large amount of data to OpenSSL, and causing the length calculation
here to become negative:

            /* suck in c.slen bytes of data */
            want=(int)c.slen;
            if (want > (len-off))
                {
                want-=(len-off);
                if (!BUF_MEM_grow_clean(b,len+want))
                    {
                    ASN1err(ASN1_F_ASN1_D2I_READ_BIO,ERR_R_MALLOC_FAILURE);
                    goto err;
                    }

Because want is a signed int, the sign extension to size_t for
BUF_MEM_grow_clean means an unexpectedly size_t is produced. An
example is probably helpful:

(gdb) bt
#0  asn1_d2i_read_bio (in=0x9173a0, pb=0x7fffffffd8f0) at a_d2i_fp.c:223
#1  0x[PII_REDACTED]524ce8 in ASN1_item_d2i_bio (it=0x62d740, in=0x9173a0, x=0x0) at a_d2i_fp.c:112
#2  0x[PII_REDACTED]54c132 in d2i_X509_bio (bp=0x9173a0, x509=0x0) at x_all.c:150
#3  0x[PII_REDACTED]43b7a7 in load_cert (err=0x8a1010, file=0x0, format=1, pass=0x0, e=0x0, cert_descrip=0x5ebcc0 "Certificate") at apps.c:819
#