[FD] Qualys Security Advisory - LibreSSL (CVE-2015-5333 and CVE-2015-5334)

Qualys Security Advisory LibreSSL (CVE-2015-5333 and CVE-2015-5334) ======================================================================== Contents ======================================================================== Summary Memory Leak (CVE-2015-5333) Buffer Overflow (CVE-2015-5334) Acknowledgments ======================================================================== Summary ======================================================================== In order to achieve remote code execution against the vulnerabilities that we recently discovered in OpenSMTPD (CVE-2015-7687), a memory leak is needed. Because we could not find one in OpenSMTPD itself, we started to review the malloc()s and free()s of its libraries, and eventually found a memory leak in LibreSSL's OBJ_obj2txt() function; we then realized that this function also contains a buffer overflow (an off-by-one, usually stack-based). The vulnerable function OBJ_obj2txt() is reachable through X509_NAME_oneline() and d2i_X509(), which is called automatically to decode the X.509 certificates exchanged during an SSL handshake (both client-side, unless an anonymous mode is used, and server-side, if client authentication is requested). These vulnerabilities affect all LibreSSL versions, including LibreSSL 2.0.0 (the first public release) and LibreSSL 2.3.0 (the latest release at the time of writing). OpenSSL is not affected. ======================================================================== Memory Leak (CVE-2015-5333) ======================================================================== OBJ_obj2txt() converts an ASN.1 object identifier (the ASN1_OBJECT a) into a null-terminated string of numerical subidentifiers separated by dots (at most buf_len bytes are written to buf). Large subidentifiers are temporarily stored in a BIGNUM (bl) and converted by BN_bn2dec() into a printable string of decimal characters (bndec). Many such bndec strings can be malloc()ated and memory-leaked in a loop, because only the last one will be free()d, after the end of the loop: 489 int 490 OBJ_obj2txt(char *buf, int buf_len, const ASN1_OBJECT *a, int no_name) 491 { ... 494 char *bndec = NULL; ... 516 len = a->length; ... 519 while (len > 0) { ... 570 bndec = BN_bn2dec(bl); 571 if (!bndec) 572 goto err; 573 i = snprintf(buf, buf_len, ".%s", bndec); ... 598 } ... 601 free(bndec); ... 609 } This memory leak allows remote attackers to cause a denial of service (memory exhaustion) or trigger the buffer overflow described below. ======================================================================== Buffer Overflow (CVE-2015-5334) ======================================================================== As a result of CVE-2014-3508, OBJ_obj2txt() was modified to "Ensure that, at every state, |buf| is NUL-terminated." However, in LibreSSL, the error-handling code at the end of the function may write this null-terminator out-of-bounds: 489 int 490 OBJ_obj2txt(char *buf, int buf_len, const ASN1_OBJECT *a, int no_name) 491 { ... 516 len = a->length; 517 p = a->data; 518 519 while (len > 0) { ... 522 for (;;) { 523 unsigned char c = *p++; 524 len--; 525 if ((len == 0) && (c & 0x80)) 526 goto err; ... 528 if (!BN_add_word(bl, c & 0x7f)) 529 goto err; ... 535 if (!bl && !(bl = BN_new())) 536 goto err; 537 if (!BN_set_word(bl, l)) 538 goto err; ... 542 if (!BN_lshift(bl, bl, 7)) 543 goto err; ... 546 } ... 553 if (!BN_sub_word(bl, 80)) 554 goto err; ... 561 if (buf_len > 1) { 562 *buf++ = i + '0'; 563 *buf = '\0'; 564 buf_len--; 565 } ... 569 if (use_bn) { 570 bndec = BN_bn2dec(bl); 571 if (!bndec) 572 goto err; 573 i = snprintf(buf, buf_len, ".%s", bndec); 574 if (i == -1) 575 goto err; 576 if (i >= buf_len) { 577 buf += buf_len; 578 buf_len = 0; 579 } else { 580 buf += i; 581 buf_len -= i; 582 } ... 584 } else { 585 i = snprintf(buf, buf_len, ".%lu", l); 586 if (i == -1) 587 goto err; 588 if (i >= buf_len) { 589 buf += buf_len; 590 buf_len = 0; 591 } else { 592 buf += i; 593 buf_len -= i; 594 } ... 597 } 598 } 599 600 out: ... 603 return ret; 604 605 err: 606 ret = 0; 607 buf[0] = '\0'; 608 goto out; 609 } First, in order to trigger this off-by-one buffer overflow, buf must be increased until it points to the first out-of-bounds character (i.e., until buf_len becomes zero): - on the one hand, this is impossible with the code blocks at lines 561-564, 579-581, and 591-593; - on the other hand, this is very easy with the code blocks at lines 576-578 and 588-590 (the destination buffer is usually quite small; for example, it is only 80 bytes long in X509_NAME_oneline()). Second, the code must branch to the err label: - the "goto err"s at lines 574-575 and 586-587 are unreachable, because snprintf() cannot possibly return -1 here; - the "goto err" at lines 525-526 is: . very easy to reach in LibreSSL <= 2.0.4; . impossible to reach in LibreSSL >= 2.0.5, because of the "MSB must be clear in the last octet" sanity check that was added to c2i_ASN1_OBJECT(): 286 /* 287 * Sanity check OID encoding: 288 * - need at least one content octet 289 * - MSB must be clear in the last octet 290 * - can't have leading 0x80 in subidentifiers, see: X.690 8.19.2 291 */ 292 if (len <= 0 || len > INT_MAX || pp == NULL || (p = *pp) == NULL || 293 p[len - 1] & 0x80) { 294 ASN1err(ASN1_F_C2I_ASN1_OBJECT, ASN1_R_INVALID_OBJECT_ENCODING); 295 return (NULL); 296 } - the remaining "goto err"s are triggered by error conditions in various BIGNUM functions: . either because of a very large BIGNUM (approximately 64 megabytes, which is impossible in the context of an SSL handshake, where X.509 certificates are limited to 100 kilobytes); . or because of an out-of-memory condition (which can be reached through the memory leak described above). This off-by-one buffer overflow allows remote attackers to cause a denial of service (crash) or possibly execute arbitrary code. However, when triggered through X509_NAME_oneline() (and therefore d2i_X509()), this buffer overflow is stack-based and probably not exploitable on OpenBSD x86, where it appears to always smash the stack canary. ======================================================================== Acknowledgments ======================================================================== We would like to thank the LibreSSL team for their great work and their incredibly quick response, and Red Hat Product Security for promptly assigning CVE-IDs to these issues.

Source: Gmail -> IFTTT-> Blogger