OpenSSL 1.1.0 ssl_add_clienthello_tlsext heap-based overflow

Summaryinfo

A vulnerability has been found in OpenSSL 1.1.0 and classified as critical. Affected by this vulnerability is the function ssl_add_clienthello_tlsext. The manipulation leads to heap-based overflow. Remote exploitation of the attack is possible. Furthermore, an exploit is available.

Detailsinfo

A vulnerability was found in OpenSSL 1.1.0 (Network Encryption Software). It has been rated as critical. This issue affects the function ssl_add_clienthello_tlsext. The manipulation with an unknown input leads to a heap-based overflow vulnerability. Using CWE to declare the problem leads to CWE-122. A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc(). Impacted is confidentiality, integrity, and availability.

The weakness was published 10/13/2016 by Guido Vranken as not defined mailinglist post (Full-Disclosure). The advisory is shared at seclists.org. The attack may be initiated remotely. No form of authentication is needed for a successful exploitation. Technical details as well as a public exploit are known. The following code is the reason for this vulnerability:

if ((long)(limit - ret - 7 - extlen - idlen) < 0)
    return NULL;
s2n(TLSEXT_TYPE_status_request, ret);
if (extlen + idlen > 0xFFF0)
    return NULL;
s2n(extlen + idlen + 5, ret);
*(ret++) = TLSEXT_STATUSTYPE_ocsp;
s2n(idlen, ret);
for (i = 0; i < sk_OCSP_RESPID_num(s->tlsext_ocsp_ids); i++) {
    /* save position of id len */
    unsigned char *q = ret;
    id = sk_OCSP_RESPID_value(s->tlsext_ocsp_ids, i);
    /* skip over id len */
    ret += 2;
    itmp = i2d_OCSP_RESPID(id, &ret);
    /* write id len */
    s2n(itmp, q);
}
s2n(extlen, ret);
1283if (extlen > 0)
1284    i2d_X509_EXTENSIONS(s->tlsext_ocsp_exts, &ret);

(...) if an attacker can somehow influence the ALPN list of an OpenSSL-enabled application (perhaps through another vulnerability), the attacker can write arbitrary data past OpenSSL's heap buffer.

A public exploit has been developed by Guido Vranken and been published immediately after the advisory. The exploit is available at seclists.org. It is declared as proof-of-concept. We expect the 0-day to have been worth approximately $25k-$100k. The code used by the exploit is:

openssl s_client -reconnect -status -alpn `python -c "import sys;
sys.stdout.write('x,'*4000+'x')"`

It doesn’t crash immediately after ‘ret’ crosses ‘limit’ because the buffer is over-allocated by the code in crypto/buffer/buffer.c (...) And just to be clear, you don’t need to modify the source code of the client in order to make this work. You only need to modify the server code (a separate build if you want) so it sends large tickets.

The mailinglist post contains the following remark:

Triggering this requires that the client sets a very large ALPN list (several thousand bytes). This would be very unusual in a real-world application. For this reason OpenSSL does not treat this as a security vulnerability and I am inclined to agree with this decision.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Productinfo

Type

• Network Encryption Software

Name

• OpenSSL

Version

• 1.1.0

License

• open-source

Support

• end of life (old version)

Website

• Product: https://www.openssl.org/

CPE 2.3info

• 🔍

CPE 2.2info

• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion