Assignment: Final Assignment

Antony Kungu
CSOL 560
Masters of Science in Cyber Security Operations and
Leadership
University of San Diego
April 30th, 2017
Table of Contents
Introduction ................................................................................................................................................... 3
CVE-2014-0160 – Heart Bleed ..................................................................................................................... 3
Deployment and implementation .................................................................................................................. 4
Scope of the problem .................................................................................................................................... 5
OpenSSL rewrite or Fix? .............................................................................................................................. 7
How would the redesigned OpenSSL be tested? .......................................................................................... 8
Works Cited .................................................................................................................................................. 9

2
Introduction

OpenSSL is an open source project that provides a robust, commercial-grade, and full-featured
toolkit for the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. It is
also a general-purpose cryptography library. OpenSSL toolkit is licensed under an Apache-style
license, which basically means that you are free to get and use it for commercial and non-
commercial purposes subject to some simple license conditions. OpenSSL has had many design
flaws that have been exploited. One of the most major one that I have read about is the heart
bleed that was discovered and reported in 2014.

CVE-2014-0160 – Heart Bleed

Heartbleed is a security bug/design flaw that was disclosed in April 2014 in the OpenSSL
cryptography library, which is a widely-used implementation of the Transport Layer Security
(TLS) protocol. Heartbleed could be exploited regardless of whether the party using a vulnerable
OpenSSL instance for TLS was a server or a client. The Heartbleed Bug was a serious design
flaw in the popular OpenSSL cryptographic software library. This weakness allowed attackers to
steal the information protected, under normal conditions, by the SSL/TLS encryption used to
secure the Internet. SSL/TLS provided communication security and privacy over the Internet for
applications such as web, email, instant messaging (IM) and some virtual private networks
(VPNs). The diagram below shows how TLS worked;

3
Deployment and implementation

The Heartbleed bug allowed anyone on the Internet to read the memory of the systems protected
by the vulnerable versions of the OpenSSL software which allowed remote attackers to obtain
sensitive information from process memory via crafted packets that triggered a buffer over-read,
as demonstrated by reading private keys, related to d1_both.c and t1_lib.c. This compromised the
secret keys used to identify the service providers and to encrypt the traffic, the names and
passwords of the users and the actual content. This allowed attackers to eavesdrop on
communications, steal data directly from the services and users and to impersonate services and
users. This design flaw was called so as the Bug was in the OpenSSL's implementation of the
TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520). When it was
exploited it led to the leak of memory contents from the server to the client and from the client to
the server. The diagram below shows how TLS extension worked;

4
The diagram below shows how the exploitation was done;

Scope of the problem

The most notable software that was using OpenSSL were the open source web servers like
Apache and nginx. The combined market share of just those two out of the active sites on the
Internet was over 66% according to Netcraft's April 2014 Web Server Survey. Furthermore,
OpenSSL was used to protect for email servers (SMTP, POP and IMAP protocols), chat servers
(XMPP protocol), virtual private networks (SSL VPNs), network appliances and wide variety of
client side software. Luckily, many large consumer sites were saved by their conservative choice
of SSL/TLS termination equipment and software. Ironically smaller and more progressive

5
services or those who had upgraded to latest and best encryption were most affected. The
vulnerable versions have been out there for over three years now and they have been rapidly

adopted by modern operating systems. A major contributing factor has been that TLS versions
1.1 and 1.2 that came available with the first vulnerable OpenSSL version (1.0.1) and security
community has been pushing the TLS 1.2 due to earlier attacks against TLS known as BEAST.

Security of the code through different styles to review it could have caught this bug in advance
before it was implemented by finding these inevitable human mistakes sooner. The sensitive
information that could be retrieved because of this bug included:

 Primary key material (secret keys)

 Secondary key material (user names and passwords used by vulnerable services)
 Protected content (sensitive data used by vulnerable services)
 Collateral (memory addresses and content that can be leveraged to bypass exploit
mitigations)

The diagram below shows the layout of an attack where an individual secret keys, usernames and
passwords could be stolen;

6
The diagram above shows how a successful attack required only sending a specially crafted
message to a web server running OpenSSL. The attacker constructed a malformed "heartbeat
request" with a large field length and small payload size. The vulnerable server did not validate
that the length of the payload against the provided field length and returned up to 64 kB of server
memory to the attacker. It was likely that this memory was previously utilized by OpenSSL.
Data returned contained sensitive information such as encryption keys or user names and
passwords that could be used by the attacker to launch further attacks.

OpenSSL rewrite or Fix?

This is a question many security professionals and leaders have grappled with for a long time.
OpenSSL bugs have increased in tally and rapidly growing causing major security issues with
the OpenSSL Library. The questions remain that should it be re-written, redesigned from scratch
or keep on patching it up? None of the options is easy however if OpenSSL was to be redesigned
these are the resources that would be needed since this would be a massive undertaking;

(a) Project Lead – this would be the head to ensure that the project doesn’t derail
(b) Package maintainers - The task of distributing such a widely-used library across every
OS/distro combination is huge. The support from all the people who code for the
different OS/distro would be needed to actually happen. Without proper packaging a
library will never see the adoption it is looking for. With the growing number of package
systems and OS distributions, this can be a challenging task.
(c) OS/Arch experts - Cross OS compatibility is tough and folks who understand the
intricacies of all the major OSes and CPU architectures will be in high demand. With the
likely implementation language remaining to be C, ARM and embedded devices this
knowledge will be essential.
(d) Builders - OpenSSL is a reasonably sized library. While a rewrite will likely only
contain a fraction of the volume of code, there’s still a lot of work to do and skilled
coders will be needed.
(e) Code breakers – this will be security professionals who will put the code through its
paces to ensure that it is secure.
(f) Cryptographers - folks who actually understand crypto and can review the
implementations. This is absolutely essential to the success of the project.
(g) Community interfaces - to ensure success of the library, it has to remain visibly active
and support its users. This means tending to issues, working with integrators, maintaining
a blog, moderating a mailing list, and all the other community focused things that are
involved with running a library as big while answering all questions.
(h) Integrators - integration with all of the major applications that will use the library will
need to be a part of the integration process. This is the principal complication, and will
likely take the most amount of time. The web servers will likely be the first to take on
this task followed by the programming languages and other higher level libraries that use
OpenSSL. No real progress can be made until the integrations are complete.
(i) Cost – where will the funding come from to ensure this project is success.
7
In my own opinion, I do believe there is a lot of good that can come from a redesign of OpenSSL
which could help prevent some terrible default configuration issues, and potentially even create a
better “secure by default” system. If such an opportunity ever arises to create the next generation
OpenSSL I would love to be a part of it.

How would the redesigned OpenSSL be tested?

I would say that to start with, one needs to understand the code. This can be achieved by talking
to the programmers and system architects. A code walk through is a high-level walk through of
the code where the developers can explain the logic and flow of the implemented code. It allows
the code review team to obtain a general understanding of the code, and allows the developers to
explain why certain things were developed without actually doing a code review. Once the code
is understood, a static code analysis can be done using a checklist of predefined system
requirements to see how the code matches up. Once the code passes the static analysis (code
doesn’t actually execute) then it can be checked busing a tool like VisualCodeGrepper that is
commonly used to test C.

For automated source code analysis of OpenSSL library created using the C language, klocwock
can be used as it contains hundreds of checkers as the code is being executed. For dynamic
analysis, we can also use Trust Visor which is a special-purpose hypervisor that provides code
integrity as well as data integrity and secrecy for user space Pieces of Application Logic (PALs)
without trusting the host operating system. Trust Visor has a high level of security as it can
protect sensitive code at a very fine granularity, and has a very small code base that supports
verification. The trust visor is designed with in built memory protections in three basic operating
modes; Host mode that supports two guest modes i.e. legacy and secure. Secure guest mode, a
PAL executes in isolation from the legacy OS and its applications. A PAL is identified to Trust
Visor via a registration process that employs an application level hyper call interface, with the
PAL execution environment initialized by Trust Visor to a well-known secure configuration.

Conclusion

The most important thing is to ensure that the code identity and isolated code execution is front
and center while ensuring security and integrity of the new OpenSSL library. Flicker allows code
to verifiably execute with hardware enforced isolation. Conversely, Design and Implementation
of a TCG-based Integrity Measurement Architecture emphasizes the implementation and design
of a secure integrity measurement system.

8
Works Cited
Common Vulnerabilities and Exposures. (2017, January 05). Retrieved April 08, 2017, from
MITRE organaisation: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3192

Computer Security Resource Center. (2017, january). Retrieved April 02, 2017, from
Nationational Vulnerability Database: https://nvd.nist.gov/vuln/detail/CVE-2015-3193

OpenSSL Security Advisory [26 Jan 2017]. (2017, january 26th). Retrieved April 02, 2017, from
OpenSSL organiosation: https://www.openssl.org/news/secadv/20170126.txt

OpenSSL TLS heartbeat extension read overflow discloses sensitive information. (2014).
Retrieved from CERT: https://www.kb.cert.org/vuls/id/720951

Symantec connect. (2017, March 08). Retrieved April 02, 2017, from Security Focus:
http://www.securityfocus.com/bid/96719

The Heartbleed Bug. (2014, January 05). Retrieved from Heartbleed.com: http://heartbleed.com/