IN FEBRUARY, APPLE revealed and fixed a Secure Sockets
Layer (SSL) vulnerability that had gone undiscovered
since the release of iOS 6.0 in September 2012. It left
users vulnerable to man-in-the-middle attacks thanks
to a short circuit in the SSL/TLS (Transport Layer
Security) handshake algorithm introduced by the
duplication of a goto statement. Since the discovery
of this very serious bug, many people have written
about potential causes. A close inspection of the code,
however, reveals not only how a unit test could have
been written to catch the bug, but also how to refactor
the existing code to make the algorithm testable—as
well as more clues to the nature of the error and the
environment that produced it.
This article addresses five big questions about the
SSL vulnerability: What was the bug (and why was it
bad)? How did it happen (and how
didn’t it)? How could a test have caught
it? Why didn’t a test catch it? How can
we fix the root cause?
The Apple SSL vulnerability, formally
labeled CVE-2014-1266, was produced
by the inclusion of a spurious, unconditional goto statement that bypassed
the final step in the SSL/TLS handshake
algorithm. According to the National
Vulnerability Database (http://web.
CVE-2014-1266) and the Common Vulnerabilities and Exposure (CVE) Standard Vulnerability Entry (http://cve.
CVE-2014-1266), the bug existed in the
versions of iOS, OS X, and the Apple TV
operating system shown in the accompanying table.
These formal reports describe the
bug as follows: “The SSLVerifySignedServerKeyExchange function
in the Secure Transport feature in the
Data Security component…does not
check the signature in a TLS Server Key
Exchange message, which allows man-in-the-middle attackers to spoof SSL
servers by using an arbitrary private
key for the signing step or omitting the
in the Apple
Article development led by
If you see something, say something.
BY MIKE BLAND