Heartbleed Bug

---

Q&A

What is the CVE-2014-0160?

CVE-2014-0160 is the official reference vĩ đại this bug. CVE (Common Vulnerabilities and Exposures) is the Standard for Information Security Vulnerability Names maintained by MITRE. Due vĩ đại co-incident discovery a duplicate CVE, CVE-2014-0346, which was assigned vĩ đại us, should not be used, since others independently went public with the CVE-2014-0160 identifier.

Why it is called the Heartbleed Bug?

Bug is in the OpenSSL's implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520). When it is exploited it leads vĩ đại the leak of memory contents from the server vĩ đại the client and from the client vĩ đại the server.

What makes the Heartbleed Bug unique?

Bugs in single software or library come and go and are fixed by new versions. However this bug has left large amount of private keys and other secrets exposed vĩ đại the Internet. Considering the long exposure, ease of exploitation and attacks leaving no trace this exposure should be taken seriously.

Is this a design flaw in SSL/TLS protocol specification?

No. This is implementation problem, i.e. programming mistake in popular OpenSSL library that provides cryptographic services such as SSL/TLS vĩ đại the applications and services.

What is being leaked?

Encryption is used vĩ đại protect secrets that may harm your privacy or security if they leak. In order vĩ đại coordinate recovery from this bug we have classified the compromised secrets vĩ đại four categories: 1) primary key material, 2) secondary key material and 3) protected nội dung and 4) collateral.

What is leaked primary key material and how vĩ đại recover?

These are the crown jewels, the encryption keys themselves. Leaked secret keys allow the attacker vĩ đại decrypt any past and future traffic vĩ đại the protected services and vĩ đại impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed. Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable vĩ đại decryption. All this has vĩ đại be done by the owners of the services.

What is leaked secondary key material and how vĩ đại recover?

These are for example the user credentials (user names and passwords) used in the vulnerable services. Recovery from this leak requires owners of the service first vĩ đại restore trust vĩ đại the service according vĩ đại steps described above. After this users can start changing their passwords and possible encryption keys according vĩ đại the instructions from the owners of the services that have been compromised. All session keys and session cookies should be invalidated and considered compromised.

What is leaked protected nội dung and how vĩ đại recover?

This is the actual nội dung handled by the vulnerable services. It may be personal or financial details, private communication such as emails or instant messages, documents or anything seen worth protecting by encryption. Only owners of the services will be able vĩ đại estimate the likelihood what has been leaked and they should notify their users accordingly. Most important thing is vĩ đại restore trust vĩ đại the primary and secondary key material as described above. Only this enables safe use of the compromised services in the future.

What is leaked collateral and how vĩ đại recover?

Leaked collateral are other details that have been exposed vĩ đại the attacker in the leaked memory nội dung. These may contain technical details such as memory addresses and security measures such as canaries used vĩ đại protect against overflow attacks. These have only contemporary value and will lose their value vĩ đại the attacker when OpenSSL has been upgraded vĩ đại a fixed version.

Recovery sounds laborious, is there a short cut?

After seeing what we saw by "attacking" ourselves, with ease, we decided vĩ đại take this very seriously. We have gone laboriously through patching our own critical services and are dealing with possible compromise of our primary and secondary key material. All this just in case we were not first ones vĩ đại discover this and this could have been exploited in the wild already.

How revocation and reissuing of certificates works in practice?

If you are a service provider you have signed your certificates with a Certificate Authority (CA). You need vĩ đại kiểm tra your CA how compromised keys can be revoked and new certificate reissued for the new keys. Some CAs bởi this for không tính tiền, some may take a fee.

Am I affected by the bug?

You are likely vĩ đại be affected either directly or indirectly. OpenSSL is the most popular open source cryptographic library and TLS (transport layer security) implementation used vĩ đại encrypt traffic on the Internet. Your popular social site, your company's site, commerce site, hobby site, site you install software from or even sites lập cập by your government might be using vulnerable OpenSSL. Many of online services use TLS vĩ đại both vĩ đại identify themselves vĩ đại you and vĩ đại protect your privacy and transactions. You might have networked appliances with logins secured by this buggy implementation of the TLS. Furthermore you might have client side software on your computer that could expose the data from your computer if you connect vĩ đại compromised services.

How widespread is this?

The most notable software using OpenSSL are the open source trang web servers lượt thích Apache and nginx. The combined market share of just those two out of the active sites on the Internet was over 66% according vĩ đại Netcraft's April năm trước Web Server Survey. Furthermore OpenSSL is used vĩ đại protect for example gmail servers (SMTP, POP and IMAP protocols), chat servers (XMPP protocol), virtual private networks (SSL VPNs), network appliances and wide variety of client side software. Fortunately many large consumer sites are saved by their conservative choice of SSL/TLS termination equipment and software. Ironically smaller and more progressive services or those who have upgraded vĩ đại latest and best encryption will be affected most. Furthermore OpenSSL is very popular in client software and somewhat popular in networked appliances which have most inertia in getting updates.

What versions of the OpenSSL are affected?

Status of different versions:

• OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
• OpenSSL 1.0.1g is NOT vulnerable
• OpenSSL 1.0.0 branch is NOT vulnerable
• OpenSSL 0.9.8 branch is NOT vulnerable

Bug was introduced vĩ đại OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April năm trước fixes the bug.

How common are the vulnerable OpenSSL versions?

The vulnerable versions have been out there for over two 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 came available with the first vulnerable OpenSSL version (1.0.1) and security community has been pushing the TLS 1.2 due vĩ đại earlier attacks against TLS (such as the BEAST).

How about operating systems?

Some operating system distributions that have shipped with potentially vulnerable OpenSSL version:

• 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 (OpenSSL 1.0.1c 10 May 2012) 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)

Operating system distribution with versions that are 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 10.0p1 - OpenSSL 1.0.1g (At 8 Apr 18:27:46 năm trước UTC)
• FreeBSD Ports - OpenSSL 1.0.1g (At 7 Apr 21:46:40 năm trước UTC)

How can OpenSSL be fixed?

Even though the actual code fix may appear trivial, OpenSSL team is the expert in fixing it properly ví fixed version 1.0.1g or newer should be used. If this is not possible software developers can recompile OpenSSL with the handshake removed from the code by compile time option -DOPENSSL_NO_HEARTBEATS.

Should heartbeat be removed vĩ đại aid in detection of vulnerable services?

Recovery from this bug might have benefitted if the new version of the OpenSSL would both have fixed the bug and disabled heartbeat temporarily until some future version. Majority, if not almost all, of TLS implementations that responded vĩ đại the heartbeat request at the time of discovery were vulnerable versions of OpenSSL. If only vulnerable versions of OpenSSL would have continued vĩ đại respond vĩ đại the heartbeat for next few months then large scale coordinated response vĩ đại reach owners of vulnerable services would become more feasible. However, swift response by the Internet community in developing online and standalone detection tools quickly surpassed the need for removing heartbeat altogether.

Can I detect if someone has exploited this against me?

Exploitation of this bug does not leave any trace of anything abnormal happening vĩ đại the logs.

Can IDS/IPS detect or block this attack?

Although the heartbeat can appear in different phases of the connection setup, intrusion detection and prevention systems (IDS/IPS) rules vĩ đại detect heartbeat have been developed. Due vĩ đại encryption differentiating between legitimate use and attack cannot be based on the nội dung of the request, but the attack may be detected by comparing the size of the request against the size of the reply. This implies that IDS/IPS can be programmed vĩ đại detect the attack but not vĩ đại block it unless heartbeat requests are blocked altogether.

Has this been abused in the wild?

We don't know. Security community should deploy TLS/DTLS honeypots that entrap attackers and vĩ đại alert about exploitation attempts.

Can attacker access only 64k of the memory?

There is no total of 64 kilobytes limitation vĩ đại the attack, that limit applies only vĩ đại a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory nội dung until enough secrets are revealed.

Is this a MITM bug lượt thích Apple's goto fail bug was?

No, this does not require a man in the middle attack (MITM). Attacker can directly tương tác the vulnerable service or attack any user connecting vĩ đại a malicious service. However in addition vĩ đại direct threat the theft of the key material allows man in the middle attackers vĩ đại impersonate compromised services.

Does TLS client certificate authentication mitigate this?

No, heartbeat request can be sent and is replied vĩ đại during the handshake phase of the protocol. This occurs prior vĩ đại client certificate authentication.

Does OpenSSL's FIPS mode mitigate this?

No, OpenSSL Federal Information Processing Standard (FIPS) mode has no effect on the vulnerable heartbeat functionality.

Does Perfect Forward Secrecy (PFS) mitigate this?

Use of Perfect Forward Secrecy (PFS), which is unfortunately rare but powerful, should protect past communications from retrospective decryption. Please see https://twitter.com/ivanristic/status/453280081897467905 how leaked tickets may affect this.

Can heartbeat extension be disabled during the TLS handshake?

No, vulnerable heartbeat extension code is activated regardless of the results of the handshake phase negotiations. Only way vĩ đại protect yourself is vĩ đại upgrade vĩ đại fixed version of OpenSSL or vĩ đại recompile OpenSSL with the handshake removed from the code.

Who found the Heartbleed Bug?

This bug was independently discovered by a team of security engineers (Riku, Antti and Matti) at Codenomicon and Neel Mehta of Google Security, who first reported it vĩ đại the OpenSSL team. Codenomicon team found heartbleed bug while improving the SafeGuard feature in Codenomicon's Defensics security testing tools and reported this bug vĩ đại the NCSC-FI for vulnerability coordination and reporting vĩ đại OpenSSL team.

What is the Defensics SafeGuard?

The SafeGuard feature of the Codenomicon's Defensics security testtools automatically tests the target system for weaknesses that compromise the integrity, privacy or safety. The SafeGuard is systematic solution vĩ đại expose failed cryptographic certificate checks, privacy leaks or authentication bypass weaknesses that have exposed the Internet users vĩ đại man in the middle attacks and eavesdropping. In addition vĩ đại the Heartbleed bug the new Defensics TLS Safeguard feature can detect for instance the exploitable security flaw in widely used GnuTLS open source software implementing SSL/TLS functionality and the "goto fail;" bug in Apple's TLS/SSL implementation that was patched in February năm trước.

Who coordinates response vĩ đại this vulnerability?

Immediately after our discovery of the bug on 3rd of April năm trước, NCSC-FI took up the task of verifying it, analyzing it further and reaching out vĩ đại the authors of OpenSSL, software, operating system and appliance vendors, which were potentially affected. However, this vulnerability had been found and details released independently by others before this work was completed. Vendors should be notifying their users and service providers. Internet service providers should be notifying their over users where and when potential action is required.

Is there a bright side vĩ đại all this?

For those service providers who are affected this is a good opportunity vĩ đại upgrade security strength of the secret keys used. A lot of software gets updates which otherwise would have not been urgent. Although this is painful for the security community, we can rest assured that infrastructure of the cyber criminals and their secrets have been exposed as well.

What can be done vĩ đại prevent this from happening in future?

The security community, we included, must learn vĩ đại find these inevitable human mistakes sooner. Please tư vấn the development effort of software you trust your privacy vĩ đại. Donate money vĩ đại the OpenSSL project.

Where vĩ đại find more information?

This Q&A was published as a follow-up vĩ đại the OpenSSL advisory, since this vulnerability became public on 7th of April năm trước. The OpenSSL project has made a statement at https://www.openssl.org/news/secadv_20140407.txt. Individual vendors of operating system distributions, affected owners of Internet services, software packages and appliance vendors may issue their own advisories.

References

• CVE-2014-0160
• NCSC-FI case# 788210
• OpenSSL Security Advisory (published 7th of April năm trước, ~17:30 UTC)
• CloudFlare: Staying ahead of OpenSSL vulnerabilities (published 7th of April năm trước, ~18:00 UTC)
• (published 7th of April năm trước, ~19:00 UTC)
• Ubuntu / Security Notice USN-2165-1
• FreeBSD / SA-14:06.openssl
• FreshPorts / openssl 1.0.1_10
• RedHat / RHSA-2014:0376-1
• CentOS / CESA-2014:0376
• Fedora / Status on CVE-2014-0160
• CERT/CC (USA)
• CERT.at (Austria)
• CIRCL (Luxembourg)
• CERT-FR (France)
• JPCERT/CC (Japan)
• CERT-SE (Sweden)
• CNCERT/CC (People's Republic of China)
• Public Safety Canada
• LITNET CERT (Lithuania)
• UNAM-CERT (Mexico)
• SingCERT (Singapore)
• Q-CERT (Qatar)

Heartbleed logo is không tính tiền vĩ đại use, rights waived via CC0. [download logo in SVG format]

Page updated 2020-06-03 16:39 UTC.