Scribd
Upload
80 views

Survey Paper On Openssl

The document summarizes four recent high or critical vulnerabilities in the OpenSSL library. It discusses how vulnerabilities like the Heartbleed bug revealed issues with OpenSSL's design and coding practices. Specifically, it analyzes vulnerabilities like the Encrypt-Then-Mac renegotiation crash in 2017, a 2016 ChaCha20/Poly1305 heap buffer overflow, a 2016 use after free vulnerability caused by message relocation, and a 2016 unbounded memory growth issue from OCSP requests. The document concludes that a lack of standardized code, error checking, and documentation have contributed to OpenSSL vulnerabilities.

Uploaded by

api-403267489
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
80 views

Survey Paper On Openssl

The document summarizes four recent high or critical vulnerabilities in the OpenSSL library. It discusses how vulnerabilities like the Heartbleed bug revealed issues with OpenSSL's design and coding practices. Specifically, it analyzes vulnerabilities like the Encrypt-Then-Mac renegotiation crash in 2017, a 2016 ChaCha20/Poly1305 heap buffer overflow, a 2016 use after free vulnerability caused by message relocation, and a 2016 unbounded memory growth issue from OCSP requests. The document concludes that a lack of standardized code, error checking, and documentation have contributed to OpenSSL vulnerabilities.

Uploaded by

api-403267489
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

1

Survey paper on OpenSSL


Raul Mendoza
University of San Diego
Secure Software Design/Development
CSOL 560
Brian Russell
March 26, 2017
2

Introduction
OpenSSL was initially released and intended to provide users with an open-source library
that supported secure communications against eavesdropping. The open-source implementation
of the SSL and TLS protocols implements basic cryptographic functions that support multiple
computer languages. Because OpenSSL was so vastly implemented, the vulnerabilities
discovered had and currently still have the potential of affecting millions of people.
It is well known and documented that the Heartbleed bug (CVE-2014-0160) was by far
one of the most significant vulnerability discoveries that identified how bad the design and
coding practices really were within OpenSSL. Within this paper, we will identify, summarize,
and analyze more recent vulnerabilities discovered the OpenSSL library.
Related Work
Over the years, OpenSSL has been subjected to an increased number of vulnerabilities.
One could argue that the primary rational for the poor design, coding, and documentation is due
to the lack of dedicated developers. I believe, coding is like art and written in ways that differ
from developer to developer. Much like a painter that is painting a picture. Not every painter will
use the same techniques, but could still accomplish the intent of what is represented. Because
there are multiple developers that contribute to the code, we see many ways that code is being
written and executed. The image below is a screenshot of the increased number of vulnerabilities
that has transpired over the years. (MITRE, 2016, p. 1)
Vulnerability Trends Over Time
3

When reviewing the different vulnerabilities, I decided to use the Common Vulnerabilities and
Exposures (CVE) advisory list. The OpenSSL website was a valuable resource that detailed the
number of recent vulnerabilities and fixes. Below I have identified four CVEs that were
categorized as High or Critical in nature.
CVE-2017-3733 (OpenSSL advisory) [High severity] 16th February 2017:
The Encrypt-Then-Mac renegotiation crash was reported to OpenSSL on January 31st, 2017. It
was determined that OpenSSL could crash because of the renegotiation handshake process. If the
Encrypt-Then-Mac extension is negotiated, but is not in the original handshake then both the
server or client could crash ("CVE-2017-3733," 2017, para. 1).
Once it was reported, Matt Caswell of the OpenSSL development team fixed and released it to
the public. The Fix exists in OpenSSL 1.1.0e, but affected 1.1.0d, 1.1.0c, 1.1.0b, 1.1.0a, 1.1.0.
CVE-2016-7054 (OpenSSL advisory) [High severity] 10th November 2016:
The ChaCha20/Poly1305 heap-buffer-overflow attack focuses on TLS connections which are
susceptible to Denial of Service (DoS) attacks. By corrupting larger payloads, OpenSSL can
crash rendering remote SSL servers inoperable ("CVE-2016-7054," 2016, para. 1). The
vulnerability is triggered by an error when verifying the MAC. If the MAC is incorrect, the
"ChaCha20_Poly1305_Cipher" function clears the buffer used to store the decrypted ciphertext
via "memset." However, an incorrect buffer pointer passed to "memset" clears the import HEAP
structure and causes the crash.
The issue was reported on September 25th, 2016 by Robert Święcki (Google Security Team) and
was fixed in OpenSSL 1.1.0c, but affected versions 1.1.0b, 1.1.0a, 1.1.0.
CVE-2016-6309 (OpenSSL advisory) [Critical severity] 26th September 2016:
Prior to release of this Common Vulnerabilities and Exposures advisory, it was determined that a
previous patch had introduced the vulnerability released in the CVE-2016-6307 update. The
“Use After Free vulnerability” is caused by an error that occurs when relocating a message with
an overlarge message size greater than 16k. Remote attackers may access the freed buffer to
crash, or potentially execute arbitrary code on vulnerable systems. OpenSSL uses structure
"ssl_st" to handle an SSL session, and includes two important buffer pointers: "init_buf" and
init_msg. "init_buf" points to the buffer used during initialization, and "init_msg" points to the
handshake message body, which is included by the buffer pointed to by "init_buf". This
vulnerability can be exploited by accessing the incorrect "init_msg" pointer, which does not
update correspondingly when "init_buf" is updated after reallocation. ("Fix Use After Free for
large message sizes," 2016, para. 2)
The issue was reported on September 23rd, 2016 by Robert Święcki (Google Security Team) and
was fixed in OpenSSL 1.1.0b, but affected version 1.1.0a.
4

CVE-2016-6304 (OpenSSL advisory) [High severity] 22nd September 2016:


The Online Certificate Status Protocol (OCSP) Status Request extension unbounded memory
growth vulnerability can result in a DoS against servers due to unbounded memory growth. If a
malicious client repeatedly sends a large OCSP Status Request extension, a server built with a
default configuration with memory unbounded, and an exhaustion of memory will cause the
server to become inoperable. ("CVE-2016-6304," 2016, para. 1)
Reported to OpenSSL on August 29th, 2016 and was fixed in OpenSSL 1.0.1u. It affected
versions 1.0.1t, 1.0.1s, 1.0.1r, 1.0.1q, 1.0.1p, 1.0.1o, 1.0.1n, 1.0.1m, 1.0.1l, 1.0.1k, 1.0.1j, 1.0.1i,
1.0.1h, 1.0.1g, 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1.
Also fixed in OpenSSL 1.0.2i, OpenSSL 1.1.0a (Affected 1.1.0, 1.0.2h, 1.0.2g, 1.0.2f, 1.0.2e,
1.0.2d, 1.0.2c, 1.0.2b, 1.0.2a, 1.0.2)
Each of the vulnerabilities may differ in method, but result in the same outcome; DoS.
The analysis of each provided insight as to how some of these events would result in a client or
server crashing. Although the bugs were not found by OpenSSL, the response to the bugs was
relatively fast. Once discovered and reported, the patch release was sent relatively quickly.
The reality of OpenSSL is that it has become someone else’s problem. In other words,
someone else will fix the problem. When reviewing these vulnerabilities, they were found by
outside individuals. Not one was found by anyone within OpenSSL small team. If OpenSSL is to
survive, it is paramount that someone take true ownership of the code. I know this does not align
with the open-source concept, but because of the vast use, we have to make the buggy code
work.
Conclusion
When reviewing the most recent vulnerabilities associated with OpenSSL, it became
apparent that the key reason for the vulnerabilities was due to the lack of standardized code and
proper bug/error checking prior to release. A primary example of these issues was proven in the
release of the CVE-2016-6309 patch. If properly reviewed, documented, or error checked, the
critical patch could have been avoided.
Ultimately, we are faced with the vast number of lines of code that provide us OpenSSL
today. With over 300,000 lines of code we are left to deal with multiple different coding styles,
unexplained dead code, inconsistent naming conventions, inline assembly code, and lastly no
central architectural authority.
In my opinion, one of the biggest contributors to the many OpenSSL bugs, is the lack of
documentation. If users cannot understand nor read about important functions, then their ability
to properly implement OpenSSL into their environment leaves them potentially more vulnerable.
Alternatives have begun to be developed as a means to provide libraries that are more secure. A
good example of this would be LibreSSL and BoringSSL. Google used OpenSSL, but because of
its vast implementation, decided to “fork” from OpenSSL in an effort to control the number of
5

patches they would have to perform. LibreSSL was solely developed as result of the Heartbleed
bug as a means to provide a more secure implementation to SSL and TLS.
6

References
OpenSSL Security Advisory . (2017). Retrieved from
https://www.openssl.org/news/secadv/20170216.txt
OpenSSL Security Advisory. (2016). Retrieved from
https://www.openssl.org/news/secadv/20161110.txt
OpenSSL Security Advisory. (2016). Retrieved from
https://www.openssl.org/news/secadv/20160926.txt
OCSP Status Request extension unbounded memory growth. (2016). Retrieved from
https://www.openssl.org/news/secadv/20160922.txt
MITRE. (2016). Vulnerability Trends Over Time. Retrieved from
http://www.cvedetails.com/product/383/Openssl-Openssl.html?vendor_id=217

You might also like