SSL Heartbreak | TechSNAP 157

SSL Heartbreak | TechSNAP 157

We break down the critical flaw in OpenSSL, and explain why the Heartbleed catastrophe impacts so many systems we use. the timeline of events, and more.

Plus your great questions, our answers, and much much more.

On this week’s TechSNAP!

Thanks to:




Direct Download:

HD Video | Mobile Video | MP3 Audio | Ogg Audio | YouTube | HD Torrent | Mobile Torrent

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feeds | Torrent Feed

— Show Notes: —

Critical flaw in OpenSSL discloses usernames, passwords and possibly encryption keys

  • Two separate groups of researchers discovered a disastrous flaw in OpenSSL, the cryptographic library that protects almost all information on the Internet.
  • The flaw is in the rarely used OpenSSL feature ‘heartbeat’ which allows the client to send a block of data to the server and have it returned to the client, keeping the connection and session alive
  • The flaw stems from a missing security check, where the software assumes that the ‘length’ of the data send by the client matches the length the client included in the header. When the actual length of the data sent by the client is less than that size, the software returns a larger chunk of memory that intended, disclosing the contents of segments of memory that were recently freed
  • This flaw allows an attacker to send a malformed request and in response get up to a 64kb chunk of memory from the server that may contain sensitive information
  • There are a number of proof-of-concept tools out there, and when used against an HTTPS server, they often return the HTTP headers of recent requests, which can include POST data (usernames, password, private emails) as well as cookies and other data that could be used for session hijacking
  • There also exists the possibility that by brute forcing this exploit an attacker may get some or all of the private key used to decrypt data sent to the server over TLS. In the common case of sessions that lack the newer PFS (Perfect Forward Secrecy) feature, if an attacker managed to compromise the private key, they would be able to decrypt all traffic that was ever encrypted to that key
  • It is possible that even PFS sessions may be compromised, if the flaw also leaks the temporary tokens used to make PFS sessions unique
  • People I’ve talked to have managed to compromise data from their own servers using only very basic tools, including capturing the admin username and password for a router and hijacking a web forum session
  • Because of the risk that the private key for the SSL certificate was compromised, the proper course of action after patching all of the servers and applications, is to re-key the certificate (generate a new private key, and get a fresh certificate signed), and then revoke the old certificate. It is unclear how well the root CAs will handle the load caused by this, or how the CRL and/or OCSP infrastructures will handle the mass revocation of keys
  • Luckily, the root CA keys are not likely to have been compromised, as they will not have been on servers exposed to the Internet
  • OpenSSL provides SSL/TLS for protocols such as HTTPS (encrypted HTTP, used for online banking, logging in to services including gmail and facebook), IMAP/SMTP and POP3 (encryption for email delivery. This affects all email, and especially the usernames and passwords used to access email), chat servers (IRC and XMPP), many types of VPN (SSL VPNs like OpenVPN) and much more
  • The flaw was originally discovered by Neel Mehta of Google Security, and around the same time was independently discovered by Riku, Antti and Matti at Codenomicon. The fix was written by Adam Langley and Bodo Moeller
  • OpenSSL versions 1.0.1 through 1.0.1f (including 1.01-beta) are vulnerable. 1.0.2-beta1 is also vulnerable. Versions 1.0.0 and 0.9.8 are not affected. All users of 1.0.1 are encouraged in the strongest terms to upgrade to OpenSSL 1.0.1g (or 1.0.2-beta2).
  • Questions are being raised about the fumbling of the responsible disclosure. It seems some companies like CloudFlair and CacheFly were notified as much as a week before anyone else.
  • Amazon appears to have not been given any advanced warning – A later post describes steps customers should take
  • Also, the security officers of major open source projects including all of the BSDs, Debian/Ubuntu, Suse etc, received absolutely no advanced warning, just the initial security advisory.
  • It appears that RedHat has approximately 2 days warning because one of the OpenSSL developers is also on their security team
  • The researchers at Codenomicon notified the National Cyber Security Centre Finland (NCSC-FI) and tasked them with coordinating the disclosure to OpenSSL, operating system vendors (which should have included the various BSD and Linux projects), appliance and service vendors (Amazon, Cisco, CloudFlare etc)
  • The issue appears to be that while the responsible disclosure was being organized, someone leaked the information and forced OpenSSL to issue the advisory. This was followed quickly by the publishing of the website (by the researchers at Codenomicon) and the CloudFlare blog post.
  • It is unclear why CloudFlare was notified, but Amazon and most open source operating systems were not
  • CloudFlare Blog Post features a very long comment thread
  • Long thread discussing the issue on the Open Source Software Security list
  • Insight on the FreeBSD security process
  • Timeline:
    • 2012-01-03 – OpenSSL 1.0.1-beta1 is available
    • 2012-03-14 – OpenSSL 1.0.1 is released, first GA version with heartbeat support
    • (sometime prior to 2014-04-05): Researchers at Codenomicon and Google discover the flaw. The flaw is reported to NCSC-FI (CERT) and OpenSSL
    • 2014-04-07 05:56 – Huzaifa Sidhpurwala (RedHat) add a bug to Red Hat bugzilla
    • 2014-04-07 06:10 – Huzaifa Sidhpurwala sends a mail to linux distros list with no details but an offer to request them privately
    • 2014-04-07 11:34 – Timestamp on RedHat OpenSSL 1.0.1g build
    • 2014-04-07 ??:?? – Information about the bug leaks, forces OpenSSL to issue advisory immediately
    • 2014-04-07 16:53 – Fix is committed to OpenSSL git
    • 2014-04-07 17:27 – OpenSSL releases advisory
    • 2014-04-07 18:00 – CloudFlare posts blog entry (claiming they were notified a week ago)
    • 2014-04-07 19:00 – is published
    • 2014-04-09 – The planned disclosure of the bug was to happen here
  • Vulnerable:
    • Debian Wheezy (stable) (OpenSSL 1.0.1e-2+deb7u4)
    • Ubuntu 12.04.4 LTS (OpenSSL 1.0.1-4ubuntu5.11)
    • CentOS 6.5 (OpenSSL 1.0.1e-15)
    • Fedora 18 (OpenSSL 1.0.1e-4)
    • OpenBSD 5.3 and 5.4 (OpenSSL 1.0.1c 10 May 2012)
    • FreeBSD 10.0 (OpenSSL 1.0.1e 11 Feb 2013)
    • NetBSD 5.0.2 (OpenSSL 1.0.1e)
    • OpenSUSE 12.2 (OpenSSL 1.0.1c)
  • Not Vulnerable:
    • Debian Squeeze (oldstable) (OpenSSL 0.9.8o-4squeeze14)
    • SUSE Linux Enterprise Server
    • FreeBSD 8.4 (OpenSSL 0.9.8y 5 Feb 2013)
    • FreeBSD 9.2 (OpenSSL 0.9.8y 5 Feb 2013)
    • FreeBSD Ports – OpenSSL 1.0.1g (At 7 Apr 21:46:40 2014 UTC)
  • It is not clear how many appliances are vulnerable, but many consumer grade appliances are likely to be vulnerable and unlikely to receive a fix. If the only solution for these devices is to throw them in the trash and replace them, the issue remains that it would likely take 2-12 months for fresh embedded devices to make it to stores where users could buy new ones
  • Analysis:
  • Canada Halts Online Tax-Filing Services
  • The Heartbleed Hit List: The Passwords You Need to Change Right Now
  • Additional Coverage – The Register
  • Additional Coverage – Washington Post
  • Additional Coverage – ThreatPost
  • IDS Signature for detecting heartbleed
  • What you should know about heartbleed
  • Critical crypto bug exposes Yahoo Mail, other passwords Russian roulette-style
  • FreeBSD Security Advisory


Round Up:

Question? Comments? Contact us here!