what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

Qualys Security Advisory - LibreSSL Leak / Overflow

Qualys Security Advisory - LibreSSL Leak / Overflow
Posted Oct 18, 2015
Authored by Qualys Security Advisory

Qualys discovered various vulnerabilities in LibreSSL. These include a memory leak and a buffer overflow.

tags | advisory, overflow, vulnerability, memory leak
advisories | CVE-2015-5333, CVE-2015-5334
SHA-256 | b0de9f18c202a6ac93d7fb4c44048d40aa246b6dbb04fa3756ef345d6a3bb3ef

Qualys Security Advisory - LibreSSL Leak / Overflow

Change Mirror Download

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.
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    12 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close