Generating the Exploit for OpenSSL 1.1.0a, b CVE-2016-7054 Part 2/3

OpenSSL 1.1.0a, b Vulnerability

Continuing the previous post, now that we know what MACs are and how they work in the context of TLS protocol we can move further ahead and analyze OpenSSL 1.1.0a and 1.1.0b Heap Overflow vulnerability. To exploit this vulnerability (cve-2016-7054) we need to negotiate a ChaCha20-Poly1305 cipher suite with the server and send a message with a bad mac. Let us first setup the server that’s running OpenSSL 1.1.0a.

Setting Up OpenSSL 1.1.0a

We can download the desired version from, after decompressing the archive, we configure the package but since we don’t want it to overwrite our current installed version of OpenSSL, we configure it like this:

and then make & make install the package. We then run generate the certificates and keys and setup OpenSSL to listen for incoming TLS connections:

Connecting to the server using ChaCha20-Poly1305 with bad MAC

In order to do this, I searched for Network TLS Fuzzers available on the internet, there’s two famous python packages for this purpose:

1. Scapy-SSL_TLS (

This package is built on top of Scapy and lets you build TLS messages in scapy’s fluent format. For example this code creates client key exchange and change cipher spec messages:

While this package is user friendly and easy to use, unfortunately it’s built on top of Python’s CryptoDomex package which does not support Poly1305 yet. So for our purpose we have to find another library.

2. TLSFuzzer (

This package is based on tlslite-ng package which handles TLS sockets and is written in python and it so happens to support ChaCha20-Poly1305 cipher suites. This sample piece of code fuzzes the mac part of TLS messages:

Exploiting the vulnerability

Using TLS Fuzzer and its fuzz_application_data functionality we can send a bad mac to our vulnerable OpenSSL instance (

If the OpenSSL instance  is not vulnerable, it replies with bad_record_mac alert and closes the connection whereas a vulnerable instance crashes:


I decided to provide this sample code for developer teams to be able to test their custom stacks and products against this vulnerability which may be based on or a fork of OpenSSL library. The fix was provided in OpenSSL 1.1.0c onwards by setting the “out” pointer to the beginning of ciphertext rather than its end. Updating fixes the issue. I have to point out that the impact is limited to Denial of Service only.

%d bloggers like this: