BT

Heartbleed allows dumping client and server memory remotely

by Alex Blewitt on Apr 09, 2014 |

The CVE-2014-0160 (and discovered as a duplicate CVE-2014-0346) is a critical flaw in OpenSSL implementations from 1.0.1 through 1.0.f that allows a remote attacker to dump random sections of memory from a server. Other versions of OpenSSL, such as 1.0.0 and 0.9.8 are not vulnerable, and the newly released versions from1.0.1g resolve the issue. OpenSSH is not affected.

The vulnerable versions of OpenSSL have been available for the last two years, and thanks to 1.0.1's introduction of TLS 1.1 and 1.2 (which themselves were the reaction to the BEAST attack) have seen widespread use. Only OSX has stayed on the older 0.9.8 versions, and as such, is generally not affected by this bug, including web-based mail sites such as Yahoo! mail and cloud computing organisations such as Amazon Web Services. According to @ivanristic, the pulse data set shows around 30% of servers support TLS 1.2, most of which are probably vulnerable to this flaw.

The flaw comes from and is named after the heartbeat extension (RFC 6520), added in OpenSSL 1.0.1, contained a bug which didn't perform the necessary range checking. The heartbeat protocol sends a memory packet to the server (of up to 64k), and then copies it back and sends it to the client. The data sent includes a payload length header, but by sending less data than claimed it is possible for a single request to read 64k of data from the server's memory.

Because the server allocation comes from a malloc'd memory array, this allows the remainder of the memory to leak potentially sensitive information from a remote server. Although there is no guarantee of the address of memory to be read, 64k is enough to capture segments of URLs which may include plain-text user/password data and is already implicated in people losing access to their accounts. It's also possible to acquire private key material, session keys or other session tickets.

The version of OpenSSL has been patched and made available in most Linux distributions, and made available through security update centres. Anyone administering a server which may use Apache, ngnix, or any other library that uses OpenSSL should apply the security updates and then restart affected processes, or just reboot the server to ensure that older versions are purged from memory.

Separately users should assume that any users/passwords that you have used to log into sites over the last few days are probably subject to compromise, and should be changed. Similarly, any certificates that have been used to protect sensitive data should be re-generated.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

checking if a domain is vulnerable by Simon BASLE

if you are cautious and want to check if a domain is vulnerable before login in an https section, you can use Filippo Valsorda service at filippo.io/Heartbleed/

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT