How Apple dodged the Heartbleed bullet

In 2011, Apple told its developers that it would be deprecating OS X's Common Data Security Architecture including OpenSSL, describing it as an outdated relic of the late 1990s. Nearly three years later, OpenSSL was hit by a severe flaw that affected a wide swath of vendors and their users, but not Apple.

When it announced plans to deprecate OpenSSL in June 2011, Apple wasn't aware of the Heartbleed flaw because it didn't yet exist. However, the company was aware of other problems with OpenSSL (libcrypto), a security toolkit Apple began using within the Common Data Security Architecture more than a decade ago.

CDSA, according to the Open Group that designed it, "is a set of layered security services and cryptographic framework that provide an infrastructure for creating cross-platform, interoperable, security-enabled applications for client-server environments is an architecture."

Apple incorporated support for CDSA and OpenSSL in its early development of Mac OS X. In 2004, Apple was recommending that Mac developers adopt CDSA, noting that it "will improve the overall performance of the system by reducing the number of libraries that frameworks link against to do cryptography."

As the company noted in its Mac security documentation from a decade ago, "CDSA is an Open Source security architecture adopted as a technical standard by the Open Group. Apple has developed its own Open Source implementation of CDSA, available as part of Darwin at Apple's Open Source site. This API provides a wide array of security services, including fine-grained access permissions, authentication of users' identities, encryption, and secure data storage."

Apple builds its own security architecture

By at least 2006 however, Apple began working on a new cryptography API for the future, designed to use less code, run faster and support concurrent use of multiple processors. These features were not only necessary for future Macs, but would also be critically important to iOS. Apple began working on a new cryptography API for the future, designed to use less code, run faster and support concurrent use of multiple processors

The desire to build a streamlined, modern security architecture was also driven by a need for FIPS 140-2 validation, required to sell devices to a variety of U.S. government agencies. As sales of iPhone and later iPad began to explode, Apple's efforts to address a robust alternative to the outdated CDSA took on new urgency.

The first step was Common Crypto, a low level C framework supporting core encryption algorithms Apple first released for OS X 10.5 Leopard in 2007 and later brought to iOS 5 in 2011. Apple has continued to work on making low level crypto functions easier for developers to use.

That includes Apple's OS X Security Transforms package, which is deeply integrated with Grand Central Dispatch to enable pipelines of data (including encryption tasks) to be spread out across available processors. It also supports hardware acceleration of crypto functions on modern processors like Intel's Core i5 and i7.

Apple deprecates CDSA & OpenSSL

By 2011, Apple was ready to deprecate CDSA, noting to developers at its WWDC event that the architecture was based on an Open Group standard that few other vendors supported besides Apple, and included lots of features nobody actually used. That required Apple to assume and manage a lot of complex external issues without any real cross-platform benefit.

"CDSA has its own standard programming interface, it is complex and does not follow standard Apple programming conventions," the company noted to its developers in Mac security documentation. iOS never incorporated CDSA, and both OS X and iOS "include their own higher-level security APIs that abstract away much of that complexity."

Building its own security software meant that Apple and its developers were no longer captive to the external development issues and eccentricities related to the OpenSSL open source project, which despite its critical importance and broad use by the industry, was being funded through donations and was, incredibly, maintained by a very small team of just four core developers."OpenSSL does not provide a stable API from version to version. For this reason, although OS X provides OpenSSL libraries, the OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS. Use of the OS X OpenSSL libraries by apps is strongly discouraged "

"Although OpenSSL is commonly used in the open source community," Apple stated in its documentation, "OpenSSL does not provide a stable API from version to version. For this reason, although OS X provides OpenSSL libraries, the OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS. Use of the OS X OpenSSL libraries by apps is strongly discouraged.

"If your app depends on OpenSSL, you should compile OpenSSL yourself and statically link a known version of OpenSSL into your app. This use of OpenSSL is possible on both OS X and iOS. However, unless you are trying to maintain source compatibility with an existing open source project, you should generally use a different API."

Apple's concern about OpenSSL lacking a "stable API from version to version" relates to the complications it would face in trying to update or patch security flaws in the open source software package in a way that wouldn't break third party apps wired to a previous version of OpenSSL. Deprecating OpenSSL in favor of its own software meant that Apple had greater control in managing its own platform.

A broad variety of vulnerabilities in Apple's OS X software have actually related to outside software that Apple has bundled with its own, including both open source software packages and third party commercial components like Adobe Flash.

Heartbleed hits OpenSSL

Apple's timing proved to be fortuitous. Just six months after Apple officially deprecated OpenSSL, the Heartbleed flaw was inadvertently introduced in OpenSSL via a Heartbeat feature designed to keep secure connections alive and active. The flawed Heartbeat feature was included in the following March 2012 release of OpenSSL, and enabled by default.

While Apple had been advising its Mac and iOS developers to use other software before the bug had ever been introduced and never distributed the subsequent versions of OpenSSL that incorporated the security flaw, much of the rest of the industry had been standardizing on the latest, freely available version of OpenSSL.

More than two years later, a researcher at Google discovered that the OpenSSL Heartbeat feature was flawed, potentially allowing a malicious user to "bleed" data from a server using an affected version of OpenSSL, and possibly even recover security keys that could be used to spy on intercepted streams of encrypted data. Client software affected by Heartbleed could also be exploited by a malicious server.

"Servers vulnerable to Heartbleed are less secure than they would be if they simply had no encryption at all," noted a report by The Guardian

According to a report by Brendan Sasso of the National Journal, Google began work on addressing the flaw internally without telling anyone else about it, not even the U.S. government, which ostensibly wasn't aware of the vulnerability until Google first disclosed it on April 1 via the company's Google Plus social network.

A timeline compiled by Ben Grubb of the Sydney Morning Herald indicates that various firms over the next week battled both for publicity and against public disclosure of the Heartbleed flaw, with security companies seizing upon it as a way to make a name for themselves, and those affected scrambling to address the problem before they and their clients could be exploited by third parties armed with the same knowledge.

The perceived advantage of open software being innately more secure through broad use and exposure to more eyeballs ran into the reality of disadvantages involved with broad industry reliance upon a widely distributed monoculture of software developed by relatively few people who didn't necessarily share the same design goals as their broad spectrum of users (including that lack of interest in maintaining API compatibility).

A flaw in Apple's own code

Apple and its Mac and iOS users weren't affected by Heartbleed, but just weeks before, the company had been hit by a similar vulnerability related to a flaw in Apple's own code, which just happened to also be related to SSL certificate based security.

In Apple's case, the flaw, branded as "GoToFail," related to code the company maintained itself, although like OpenSSL, Apple's code had also been published as open source. As with OpenSSL, merely being open to eyeballs didn't result in Apple's code being free of undiscovered flaws.

Apple was condemned in a series of posts laced with profanity for patching iOS first (before GoToFail was publicly known about) and not releasing a patch for OS X until three days later.

In contrast, it took a week for the various parties involved in Heartbleed to even coordinate its disclosure, with embargo leaks informing some clients, including OpenSSL, Akamai and Facebook as much as several days before the general public and even major companies including Cisco, Dropbox, Juniper, Twitter, Ubuntu and Yahoo.

Another security flaw, similarly affecting network security, was identified in Android's WebView 16 months ago. While much more serious in that it provided full control of a device to remote malicious users and had functional tools available that allowed virtually anyone to exploit the flaw, roughly 75 percent of Android devices appear to remain vulnerable.