CVE-2012-2110 : Detail

CVE-2012-2110

Overflow
11.96%V3
Network
2012-04-19
15h00 +00:00
2018-01-04
19h57 +00:00
CVE.org
NVD
Notifications for a CVE
Stay informed of any changes for a specific CVE.
Notifications manage

CVE Descriptions

The asn1_d2i_read_bio function in crypto/asn1/a_d2i_fp.c in OpenSSL before 0.9.8v, 1.0.0 before 1.0.0i, and 1.0.1 before 1.0.1a does not properly interpret integer data, which allows remote attackers to conduct buffer overflow attacks, and cause a denial of service (memory corruption) or possibly have unspecified other impact, via crafted DER data, as demonstrated by an X.509 certificate or an RSA public key.

CVE Informations

Related Weaknesses

CWE-ID Weakness Name Source
CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.

Metrics

Metrics Score Severity CVSS Vector Source
V2 7.5 AV:N/AC:L/Au:N/C:P/I:P/A:P [email protected]

EPSS

EPSS is a scoring model that predicts the likelihood of a vulnerability being exploited.

EPSS Score

The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

EPSS Percentile

The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other CVE.
EPSS First.org

Exploit information

Exploit Database EDB-ID : 18756

Publication date : 2012-04-18 22h00 +00:00
Author : Tavis Ormandy
EDB Verified : Yes

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 2147483648: [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 = 2147483648 (gdb) p want $19 = -2147483648 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 specified 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 0x0000000000524ce8 in ASN1_item_d2i_bio (it=0x62d740, in=0x9173a0, x=0x0) at a_d2i_fp.c:112 #2 0x000000000054c132 in d2i_X509_bio (bp=0x9173a0, x509=0x0) at x_all.c:150 #3 0x000000000043b7a7 in load_cert (err=0x8a1010, file=0x0, format=1, pass=0x0, e=0x0, cert_descrip=0x5ebcc0 "Certificate") at apps.c:819 #4 0x0000000000422422 in x509_main (argc=0, argv=0x7fffffffe458) at x509.c:662 #5 0x00000000004032d9 in do_cmd (prog=0x9123e0, argc=3, argv=0x7fffffffe440) at openssl.c:489 #6 0x0000000000402ee6 in main (Argc=3, Argv=0x7fffffffe440) at openssl.c:381 (gdb) list 218 want=HEADER_SIZE; 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)) (gdb) pt len type = int (gdb) pt want type = int (gdb) p len $28 = 1431655797 (gdb) p want $29 = 2147483646 (gdb) p len+want $30 = -715827853 (gdb) s BUF_MEM_grow_clean (str=0x917440, len=18446744072993723763) at buffer.c:133 (gdb) p/x len $31 = 0xffffffffd5555573 Here len+want wraps to a negative value, which is sign extended to a large size_t for BUF_MEM_grow_clean. Now the call to CRYPTO_realloc_clean() truncates this back into a signed int: CRYPTO_realloc_clean (str=0x7fff85be4010, old_len=1908874388, num=477218632, file=0x626661 "buffer.c", line=149) at mem.c:369 Now old_len > num, which openssl does not handle, resulting in this: ret = malloc_ex_func(num, file, line); memcpy(ret, str, old_len); Effectively a textbook heap overflow. It is likely this code is reachable via the majority of the d2i BIO interfaces and their wrappers, so most applications that handle untrusted data via OpenSSL should take action. Note that even if you do not use d2i_* calls directly, many of the higher level APIs will use it indirectly for you. Producing DER data to demonstrate this is relatively easy for both x86 and x64 architectures. ------------------- Solution ----------------------- The OpenSSL project has provided an updated version to resolve this issue. http://www.openssl.org/ http://www.openssl.org/news/secadv_20120419.txt ------------------- Credit ----------------------- This bug was discovered by Tavis Ormandy, Google Security Team. Additional thanks to Adam Langley also of Google for analysis and designing a fix. -- ------------------------------------- taviso at cmpxchg8b.com | pgp encrypted mail preferred -------------------------------------------------------

Products Mentioned

Configuraton 0

Openssl>>Openssl >> Version 1.0.0

Openssl>>Openssl >> Version 1.0.0

Openssl>>Openssl >> Version 1.0.0

Openssl>>Openssl >> Version 1.0.0

Openssl>>Openssl >> Version 1.0.0

Openssl>>Openssl >> Version 1.0.0

Openssl>>Openssl >> Version 1.0.0a

Openssl>>Openssl >> Version 1.0.0b

Openssl>>Openssl >> Version 1.0.0c

Openssl>>Openssl >> Version 1.0.0d

Openssl>>Openssl >> Version 1.0.0e

Openssl>>Openssl >> Version 1.0.0g

Configuraton 0

Openssl>>Openssl >> Version To (including) 0.9.8u

Openssl>>Openssl >> Version 0.9.1c

Openssl>>Openssl >> Version 0.9.2b

Openssl>>Openssl >> Version 0.9.3

Openssl>>Openssl >> Version 0.9.3a

Openssl>>Openssl >> Version 0.9.4

Openssl>>Openssl >> Version 0.9.5

Openssl>>Openssl >> Version 0.9.5

Openssl>>Openssl >> Version 0.9.5

Openssl>>Openssl >> Version 0.9.5a

Openssl>>Openssl >> Version 0.9.5a

Openssl>>Openssl >> Version 0.9.5a

Openssl>>Openssl >> Version 0.9.6

Openssl>>Openssl >> Version 0.9.6

Openssl>>Openssl >> Version 0.9.6

Openssl>>Openssl >> Version 0.9.6

Openssl>>Openssl >> Version 0.9.6a

Openssl>>Openssl >> Version 0.9.6a

Openssl>>Openssl >> Version 0.9.6a

Openssl>>Openssl >> Version 0.9.6a

Openssl>>Openssl >> Version 0.9.6b

Openssl>>Openssl >> Version 0.9.6c

Openssl>>Openssl >> Version 0.9.6d

Openssl>>Openssl >> Version 0.9.6e

Openssl>>Openssl >> Version 0.9.6f

Openssl>>Openssl >> Version 0.9.6g

Openssl>>Openssl >> Version 0.9.6h

Openssl>>Openssl >> Version 0.9.6i

Openssl>>Openssl >> Version 0.9.6j

Openssl>>Openssl >> Version 0.9.6k

Openssl>>Openssl >> Version 0.9.6l

Openssl>>Openssl >> Version 0.9.6m

Openssl>>Openssl >> Version 0.9.7

Openssl>>Openssl >> Version 0.9.7

Openssl>>Openssl >> Version 0.9.7

Openssl>>Openssl >> Version 0.9.7

Openssl>>Openssl >> Version 0.9.7

Openssl>>Openssl >> Version 0.9.7

Openssl>>Openssl >> Version 0.9.7

Openssl>>Openssl >> Version 0.9.7a

Openssl>>Openssl >> Version 0.9.7b

Openssl>>Openssl >> Version 0.9.7c

Openssl>>Openssl >> Version 0.9.7d

Openssl>>Openssl >> Version 0.9.7e

Openssl>>Openssl >> Version 0.9.7f

Openssl>>Openssl >> Version 0.9.7g

Openssl>>Openssl >> Version 0.9.7h

Openssl>>Openssl >> Version 0.9.7i

Openssl>>Openssl >> Version 0.9.7j

Openssl>>Openssl >> Version 0.9.7k

Openssl>>Openssl >> Version 0.9.7l

Openssl>>Openssl >> Version 0.9.7m

Openssl>>Openssl >> Version 0.9.8

Openssl>>Openssl >> Version 0.9.8a

Openssl>>Openssl >> Version 0.9.8b

Openssl>>Openssl >> Version 0.9.8c

Openssl>>Openssl >> Version 0.9.8d

Openssl>>Openssl >> Version 0.9.8e

Openssl>>Openssl >> Version 0.9.8f

Openssl>>Openssl >> Version 0.9.8g

Openssl>>Openssl >> Version 0.9.8h

Openssl>>Openssl >> Version 0.9.8i

Openssl>>Openssl >> Version 0.9.8j

Openssl>>Openssl >> Version 0.9.8k

Openssl>>Openssl >> Version 0.9.8l

Openssl>>Openssl >> Version 0.9.8m

Openssl>>Openssl >> Version 0.9.8m

Openssl>>Openssl >> Version 0.9.8n

Openssl>>Openssl >> Version 0.9.8o

Openssl>>Openssl >> Version 0.9.8p

Openssl>>Openssl >> Version 0.9.8q

Openssl>>Openssl >> Version 0.9.8r

Openssl>>Openssl >> Version 0.9.8s

Openssl>>Openssl >> Version 0.9.8t

Redhat>>Openssl >> Version 0.9.6-15

Redhat>>Openssl >> Version 0.9.6b-3

Redhat>>Openssl >> Version 0.9.7a-2

Configuraton 0

Openssl>>Openssl >> Version 1.0.1

Openssl>>Openssl >> Version 1.0.1

References

http://secunia.com/advisories/48899
Tags : third-party-advisory, x_refsource_SECUNIA
http://rhn.redhat.com/errata/RHSA-2012-1308.html
Tags : vendor-advisory, x_refsource_REDHAT
http://www.mandriva.com/security/advisories?name=MDVSA-2012:060
Tags : vendor-advisory, x_refsource_MANDRIVA
http://rhn.redhat.com/errata/RHSA-2012-1307.html
Tags : vendor-advisory, x_refsource_REDHAT
http://www.exploit-db.com/exploits/18756
Tags : exploit, x_refsource_EXPLOIT-DB
http://rhn.redhat.com/errata/RHSA-2012-0518.html
Tags : vendor-advisory, x_refsource_REDHAT
http://www.debian.org/security/2012/dsa-2454
Tags : vendor-advisory, x_refsource_DEBIAN
http://support.apple.com/kb/HT5784
Tags : x_refsource_CONFIRM
http://www.ubuntu.com/usn/USN-1424-1
Tags : vendor-advisory, x_refsource_UBUNTU
http://secunia.com/advisories/48895
Tags : third-party-advisory, x_refsource_SECUNIA
http://secunia.com/advisories/48847
Tags : third-party-advisory, x_refsource_SECUNIA
http://rhn.redhat.com/errata/RHSA-2012-1306.html
Tags : vendor-advisory, x_refsource_REDHAT
http://rhn.redhat.com/errata/RHSA-2012-0522.html
Tags : vendor-advisory, x_refsource_REDHAT
http://marc.info/?l=bugtraq&m=134039053214295&w=2
Tags : vendor-advisory, x_refsource_HP
http://secunia.com/advisories/57353
Tags : third-party-advisory, x_refsource_SECUNIA
http://www.securityfocus.com/bid/53158
Tags : vdb-entry, x_refsource_BID
http://marc.info/?l=bugtraq&m=133728068926468&w=2
Tags : vendor-advisory, x_refsource_HP
http://marc.info/?l=bugtraq&m=134039053214295&w=2
Tags : vendor-advisory, x_refsource_HP
http://marc.info/?l=bugtraq&m=133951357207000&w=2
Tags : vendor-advisory, x_refsource_HP
http://secunia.com/advisories/48942
Tags : third-party-advisory, x_refsource_SECUNIA
http://www.securitytracker.com/id?1026957
Tags : vdb-entry, x_refsource_SECTRACK
http://secunia.com/advisories/48999
Tags : third-party-advisory, x_refsource_SECUNIA
http://marc.info/?l=bugtraq&m=133951357207000&w=2
Tags : vendor-advisory, x_refsource_HP
http://osvdb.org/81223
Tags : vdb-entry, x_refsource_OSVDB
https://kb.juniper.net/KB27376
Tags : x_refsource_CONFIRM
http://marc.info/?l=bugtraq&m=133728068926468&w=2
Tags : vendor-advisory, x_refsource_HP