If I have a web crawler (using a non-patched version of OpenSSL) that can be coaxed to connect to an evil https-site, can they get everything from my process memory? To attack a server you can keep reconnecting to get more 64kb blocks (if I understand correctly), but can a client be forced to reconnect many times, to get more blocks?
-
9You don't have to keep reconnecting. You can hold one connection open and make as many heartbeat requests as you like. – Matt Nordhoff Apr 08 '14 at 13:49
-
2@MattNordhoff Ah - that is good to know. So clients are just as screwed. – Gurgeh Apr 08 '14 at 15:25
-
iPhone/iPad running iOS 7.1 have OpenSSL 1.0.1b built in at least in some configurations. https://discussions.apple.com/message/25441381 – MrPete Apr 13 '14 at 23:50
-
@MattNordhoff yeah. After all the purpose of the Heartbeat extension is to keep the SSL/TLS session alive. So you steal memory from the client AND keep the sessio alive to steal more. Just perfect. – Dakatine Apr 16 '14 at 17:46
-
I don't get the client side risk. What happens if: - a client has a non affected OpenSSL version and connects to - a server with an affected OpenSSL? Can be the client compromised in this case? – Teddy Sep 18 '14 at 08:03
2 Answers
Yes, clients are vulnerable to attack.
The initial security notices indicated that a malicious server can use the Heartbleed vulnerability to compromise an affected client. Sources below (all emphasis is mine).
Since then, proof of concept attacks have validated this position - it is utterly certain that clients running apps that use OpenSSL for TLS connections may be vulnerable.
...When [Heartbleed] is exploited it leads to the leak of memory contents from the server to the client and from the client to the server.
Ubuntu Security Notice USN-2165-1:
An attacker could use this issue to obtain up to 64k of memory contents from the client or server
5. Use Cases
Each endpoint sends HeartbeatRequest messages...
OpenSSL Security Advisory 07 Apr 2014:
A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.
Client applications reported to be vulnerable (Credit to @Lekensteyn except where otherwise stated):
- MariaDB 5.5.36
- wget 1.15 (leaks memory of earlier connections and own state)
- curl 7.36.0
- git 1.9.1 (tested clone / push, leaks not much)
- nginx 1.4.7 (in proxy mode, leaks memory of previous requests)
- links 2.8 (leaks contents of previous visits!)
- All KDE applications using KIO (Dolphin, Konqueror).
- Exim mailserver
- OwnCloud Version Unknown | Source
Note that some of these programs do not use OpenSSL. For example, curl can be built with Mozilla NSS and Exim can be built with GnuTLS (as is done on Debian).
Other common clients:
Windows (all versions): Probably unaffected (uses SChannel/SSPI), but attention should be paid to the TLS implementations in individual applications. For example, Cygwin users should update their OpenSSL packages.
OSX and iOS (all versions): Probably unaffected. SANS implies it may be vulnerable by saying "OS X Mavericks has NO PATCH available", but others note that OSX 10.9 ships with OpenSSL 0.9.8y, which is not affected. Apple says: "OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS"
Chrome (all platforms except Android): Probably unaffected (uses NSS)
Chrome on Android: 4.1.1 may be affected (uses OpenSSL). Source. 4.1.2 should be unaffected, as it is compiled with heartbeats disabled. Source.
Mozilla products (e.g. Firefox, Thunderbird, SeaMonkey, Fennec): Probably unaffected, all use NSS
![](../../users/profiles/1811.webp)
- 9,303
- 3
- 33
- 54
-
Which protocols are affected? Will any client that uses the OpenSSL library to manage an SSL connection automatically respond to heartbeets, or does the application protocol have to allow for it? We [started a discussion in chat](http://chat.stackexchange.com/transcript/message/14778531#14778531) about this, but it didn't get anywhere. – Gilles 'SO- stop being evil' Apr 08 '14 at 14:35
-
TLS is part of the application layer, so I suspect anything that uses the OpenSSL library and did *not* invoke DOPENSSL_NO_HEARTBEATS at compile time will be affected. – scuzzy-delta Apr 08 '14 at 14:42
-
2For my specific needs, I am not so concerned about someone decrypting my connection. I want to know if, as reported by some sources, this vulnerability can be used to read everything in the client process' memory. – Gurgeh Apr 08 '14 at 15:13
-
1As I understand it from here: http://security.stackexchange.com/questions/55116/how-exactly-does-the-openssl-tls-heartbeat-heartbleed-exploit-work?rq=1 the entire memory _should_ be reconstructable after enough heartbeats. – Gurgeh Apr 08 '14 at 15:19
-
@scuzzy-delta, It states "from the client or server", But exactly *how* do we attack the client using HeartBleed? – Pacerier Apr 08 '14 at 15:40
-
@Pacerier You attack the client by being a malicious server. Trick the client into connecting to you (e.g. phishing emails or linkbait). When the client makes a TLS connection to you, start sending them the malformed TLS heartbeat packets. – scuzzy-delta Apr 08 '14 at 15:47
-
@scuzzy-delta Phishing emails or linkbait is how you would trick a human. Client _programs_ (various scrapers, crawlers, etc) are attracted by blog pings and feeding malicious links to Hacker News, Reddit, etc. – Gurgeh Apr 08 '14 at 15:52
-
@scuzzy-delta, Assuming we have 3 parties, the real client, the real server, and the attacker. Can the attacker attack the client via the server? – Pacerier Apr 08 '14 at 15:57
-
2No, it has to be a malicious/compromised server in order to exploit the vulnerability against the client. – ack__ Apr 08 '14 at 16:04
-
I've converted this to community wiki, feel free to edit as more info comes in. – scuzzy-delta Apr 08 '14 at 22:29
-
Attacks on clients are usually not that fruitful though, because clients seldom use SSL to authenticate, so there is no key material that could be extracted and then used to impersonate the client. I'd expect such an attack to be highly targeted. – Simon Richter Apr 09 '14 at 09:46
-
1@SimonRichter Consider login information and session cookies. BREACH/CRIME made a lot fuss about that. – Lekensteyn Apr 09 '14 at 11:08
-
2@scuzzy-delta I made [Pacemaker](https://github.com/Lekensteyn/pacemaker) in an attempt to show that clients are definitely affected. The current implementation does not require valid certificates and can leak some data depending on the client. Perhaps more interesting memory can be leaked when the handshake is complete, but that requires more work. – Lekensteyn Apr 09 '14 at 11:23
-
@Lekensteyn Yes, I heard and have been watching your repo, it's really awesome stuff. Why don't you ask the right question (e.g. "What client apps have been proven to be vulnerable?"), and then [answer it yourself](http://stackoverflow.com/help/self-answer)? Your work is really useful - AFAIK it is the first PoC against clients – scuzzy-delta Apr 09 '14 at 11:46
-
1@scuzzy-delta I have posted a new [Q & A](http://security.stackexchange.com/q/55249/2630). Comments are welcome :-) – Lekensteyn Apr 09 '14 at 14:10
-
-
Regarding Mozilla products, see [this article on the Mozilla blog](http://blog.mozilla.org/security/2014/04/08/heartbleed-security-advisory/), and its comments – ignis Apr 09 '14 at 20:37
-
You say that some clients are **probably unaffected**. Why can't anybody make it absolutely clear what the status is for these clients? Can't we test this somehow? Take a client like OSX, which has a webserver built in. Isn't that a good way to test it? – SPRBRN May 26 '14 at 12:33
Yes it affects clients as severly, as stated on the heartbleed website:
Furthermore you might have client side software on your computer that could expose the data from your computer if you connect to compromised services.
Of course, and this is not just the case for this vulnerability or for a particular client, the client still has to initiate the connection to be attacked. In no way this vulnerability allows an attacker to initiate a connection to your web crawler and exploit the vulnerability.
In your case however, as you have a direct control over the OpenSSL client code (and I suppose this is the case based on your post), you want to ensure that your version of OpenSSL doesn't come with the Heartbeat option, and if it does, to remove it. In order to do so, you can:
display which specific options were used to compile your version of OpenSSL :
openssl version -o
or display every information from your OpenSSL version :
openssl version -a
compile OpenSSL without Heartbeat support, by simply using this flag at compile time :
-DOPENSSL_NO_HEARTBEATS
Once this is done, or if your version of OpenSSL didn't include it initially, then you are not vulnerable.
Edit: Another method is to retrieve your OpenSSL version with:
openssl version
And compare it to the list of affected versions available on heartbleed :
- 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
![](../../users/profiles/9604.webp)
- 2,728
- 14
- 25
-
1Do you have sources to back this up? http://heartbleed.com claims that both directions are affected. – Lekensteyn Apr 08 '14 at 13:31
-
My answer was definitely vague, I edited it. The key message was: "no, *you* are not at risk given that you have direct control over the OpenSSL client and can change your settings", as opposed to the majority of affected servers & clients that cannot be changed so easily. – ack__ Apr 08 '14 at 14:08
-
Also, sources have been given by @scuzzy-delta already. The main source of information about this bug is [http://heartbleed.com](http://heartbleed.com), and many other websites are spreading it now. – ack__ Apr 08 '14 at 14:25
-
1please bear in mind that at least redhat's fix is backported to 'e', so its no longer quite true that f(inclusive) is vulnerable – Sirex Apr 09 '14 at 03:13
-
1@Sirex There was a post on one of the other SE sites, Ubuntu apparently backported it all the way to 1.0.1, so yeah, people should check their distro's news list or other info for what is safe. – TC1 Apr 09 '14 at 09:33
-
Ubuntu's packages are patched, not really "updated" to the current OpenSSL version. Ubuntu's OpenSSL uses the source code from a branch of OpenSSL which is vulnerable, but they applied the patch (aka *backporting*). For example, Ubuntu 12.04 has `1.0.1-4ubuntu5.12`, Ubuntu 13.10 has `1.0.1e-3ubuntu1.2`. Executing `openssl version` will NOT show you the (patched) build date, but the version release. `openssl version -a` shows the build date. You can also have a look at the changelog of the package (`apt-get changelog libssl1.0.0`); it should mention the bug number `CVE-2014-0160`. – leemes Apr 11 '14 at 01:56