# Heartbleed: a serious security bug. What should I be doing? **URL:** \ **Category:** In My Humble Opinion\ **Created:** [April 8, 2014, 8:23pm UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668 "2014-04-08T20:23:15Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![tellyworth](https://avatars.discourse-cdn.com/v4/letter/t/977dab/32.png) [@tellyworth](https://boards.straightdope.com/u/tellyworth)\ **Post date:** [April 10, 2014, 1:50am UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/21 "2014-04-10T01:50:29Z")
> [@Hari\_Seldon](#): > > we should change our passwords, but there was no point in changing it until the fix was finished. They’re right - if you change your password before the problem is fixed, there’s no way to be sure the new one isn’t compromised too. It’s not all that likely that your password has been leaked by the problem. But it is likely that someone’s has, and there’s simply no way to know who is and is not safe. And once again, if you’ve used duplicate or similar passwords across multiple sites, your risk is much higher. ---
**Author:** ![CandidGamera](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/candidgamera/32/2878_2.png) [@CandidGamera](https://boards.straightdope.com/u/CandidGamera)\ **Post date:** [April 10, 2014, 1:17pm UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/22 "2014-04-10T13:17:15Z")
I just checked our servers at work, and we’re using a version of OpenSSL older than the bug, so we’re fine. Whew! ---
**Author:** ![jacobsta811](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/jacobsta811/32/2893_2.png) [@jacobsta811](https://boards.straightdope.com/u/jacobsta811)\ **Post date:** [April 10, 2014, 1:52pm UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/23 "2014-04-10T13:52:01Z")
The bug is returning RAM only. I haven’t seen this posted anywhere, but that should mean that leaked user credentials, should only be compromised _on sites you used while or just before the bug was being exploited_ which is going to be heavily, heavily tilted to the last few days. So I would change the password on all sites that I’ve used in the last say month, preferentially tilted towards site I used in the last few days. Don’t forget any sites possibly accessed by another site you gave your password to like [mint.com](http://mint.com). ---
**Author:** ![andrewm](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@andrewm](https://boards.straightdope.com/u/andrewm)\ **Post date:** [April 10, 2014, 3:01pm UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/24 "2014-04-10T15:01:37Z")
> [@Chronos](#): > > I’d like to hear more about this “effectively random” block of memory. If an attacker exploited this twice in a row on the same server, would they get back the same block of memory both times? If so, then it’s a very minor problem, since you’d only get something like a millionth of the total memory content, and any given piece of sensitive information would be very unlikely to be in that block. On the other hand, if it’s a different “random” block each time, or worse, systematically proceeds through all of the memory in the target machine, then an attacker can get a much larger amount of information. The thing is, OpenSSL uses a custom memory allocator. What that ultimately means is that the heartbeat over-read does not read random chunks of memory (which would tend to be uninteresting or cause a crash) but rather only other pieces of memory recently used by OpenSSL. That means it’s significantly more likely to contain “interesting” data (recently decrypted URLs, passwords, form data, etc). ---
**Author:** ![Claverhouse](https://avatars.discourse-cdn.com/v4/letter/c/13edae/32.png) [@Claverhouse](https://boards.straightdope.com/u/Claverhouse)\ **Post date:** [April 10, 2014, 3:18pm UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/25 "2014-04-10T15:18:25Z")
I wouldn’t bother to change your passwords on sites that don’t use encryption. Plus in three months time there’ll be another web scandal shouting the sky is falling. ---
**Author:** ![ThelmaLou](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/thelmalou/32/390_2.png) [@ThelmaLou](https://boards.straightdope.com/u/ThelmaLou)\ **Post date:** [April 10, 2014, 4:18pm UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/26 "2014-04-10T16:18:18Z")
FWIW, here’s an article in [The Atlantic](http://www.theatlantic.com/technology/archive/2014/04/how-to-check-if-a-site-is-safe-from-heartbleed/360417/) that gives links to some ways of testing individual sites. ---
**Author:** ![Leaper](https://avatars.discourse-cdn.com/v4/letter/l/4bbf92/32.png) [@Leaper](https://boards.straightdope.com/u/Leaper)\ **Post date:** [April 10, 2014, 8:46pm UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/27 "2014-04-10T20:46:37Z")
Terrific. Even with the testing tools and all that, I’m getting conflicting info on the status of the ISP for my primary e-mail and whether (or even if — it’s a huge company) it’s fixed. ---
**Author:** ![tellyworth](https://avatars.discourse-cdn.com/v4/letter/t/977dab/32.png) [@tellyworth](https://boards.straightdope.com/u/tellyworth)\ **Post date:** [April 11, 2014, 1:09am UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/28 "2014-04-11T01:09:20Z")
Just a note on passwords: there are some indications that bad guys are sending phishing emails disguised as password reset warnings prompted by Heartbleed. Take extra care clicking links in emails. ---
**Author:** ![Leaper](https://avatars.discourse-cdn.com/v4/letter/l/4bbf92/32.png) [@Leaper](https://boards.straightdope.com/u/Leaper)\ **Post date:** [April 11, 2014, 1:13am UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/29 "2014-04-11T01:13:27Z")
I should note for my last post that I check my e-mail through Thunderbird 99% of the time instead of the Web interface (which I usually use for bill paying, if that), so I have no idea what I should be checking and when. ---
**Author:** ![blindboyard](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/blindboyard/32/2833_2.png) [@blindboyard](https://boards.straightdope.com/u/blindboyard)\ **Post date:** [April 11, 2014, 11:21am UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/30 "2014-04-11T11:21:01Z")
Thunderbird still uses SSL/TLS encryption. ---
**Author:** ![Leaper](https://avatars.discourse-cdn.com/v4/letter/l/4bbf92/32.png) [@Leaper](https://boards.straightdope.com/u/Leaper)\ **Post date:** [April 11, 2014, 11:27am UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/31 "2014-04-11T11:27:14Z")
Which means…? ---
**Author:** ![Measure\_for\_Measure](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/measure_for_measure/32/557_2.png) [@Measure\_for\_Measure](https://boards.straightdope.com/u/Measure_for_Measure)\ **Post date:** [April 11, 2014, 7:38pm UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/32 "2014-04-11T19:38:11Z")
I’ve poked around with these 2 diagnostic websites: [http://filippo.io/Heartbleed/](http://filippo.io/Heartbleed/) > **[Dark Web Monitoring & Alerts - LastPass](https://www.lastpass.com/features/dark-web-monitoring)** > > Dark web monitoring now offered by LastPass. If your account information has been compromised, an alert will be sent proactively to you. Try free for a month. A number of websites appear to have patched their OpenSSL, but have not updated their certificate. Lastpass provides language like, “Possibly Unsafe (created X months ago at xxx nn 00:00:00 2013 GMT)”. What are the consequences of changing the password on a no longer vulnerable server which has old certificates? Does a residual security vulnerability remain for the user? Why and how do old certificates matter? Admittedly, I haven’t tried this recommended diagnostic: > **[SSL Server Test (Powered by Qualys SSL Labs)](https://www.ssllabs.com/ssltest/)** > > A comprehensive free SSL test for your public web servers. ---
**Author:** ![Bricker](https://avatars.discourse-cdn.com/v4/letter/b/977dab/32.png) [@Bricker](https://boards.straightdope.com/u/Bricker)\ **Post date:** [April 11, 2014, 8:01pm UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/33 "2014-04-11T20:01:09Z")
> [@Measure\_for\_Measure](#): > > I’ve poked around with these 2 diagnostic websites: > [Test your server for Heartbleed (CVE-2014-0160)](http://filippo.io/Heartbleed/) > [https://lastpass.com/heartbleed/](https://lastpass.com/heartbleed/) > > A number of websites appear to have patched their OpenSSL, but have not updated their certificate. Lastpass provides language like, “Possibly Unsafe (created X months ago at xxx nn 00:00:00 2013 GMT)”. What are the consequences of changing the password on a no longer vulnerable server which has old certificates? Does a residual security vulnerability remain for the user? Why and how do old certificates matter? > Admittedly, I haven’t tried this recommended diagnostic: > [SSL Server Test (Powered by Qualys SSL Labs)](https://www.ssllabs.com/ssltest/) If the site changed its implementation of openssl to a secure version, then it’s safe from any future incursions. But it was unsafe in the past. That means at some point in the past, an enemy could have plucked information from the site, including your credentials, and (more alarmingly) the site’s private key. This private key is what makes https secure – when you see the locked icon on your browser, you’re supposed to be able to conclude that no one in the middle of your communication can intercept it. But if the server’s private key is compromised, then that guarantee is no longer true. Someone could even impersonate that server – pretend to be your bank, for example, by running a fake server on the local WiFi at your coffee shop. In order to completely their fix, not only must the old certificate be replaced with a new one, but the old certificate should be revoked. Until that has been done, there is still risk associated with using that site. ---
**Author:** ![Measure\_for\_Measure](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/measure_for_measure/32/557_2.png) [@Measure\_for\_Measure](https://boards.straightdope.com/u/Measure_for_Measure)\ **Post date:** [April 11, 2014, 8:51pm UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/34 "2014-04-11T20:51:46Z")
Thanks much Bricker: that was helpful. Under such circumstances should I change my password on a site with solid OpenSSL but dubious certificates? [James Fallows](http://www.theatlantic.com/technology/archive/2014/04/heartbleed-update-sites-that-tell-you-which-passwords-you-should-bother-to-change/360536/) seems to [think so](http://www.theatlantic.com/technology/archive/2014/04/how-to-check-if-a-site-is-safe-from-heartbleed/360417/). I’m inclined to agree - but I see now that it might be better to avoid routine logins to websites that are not 100% secured if possible and practical. Or so I very very very tentatively hypothesize. In other news, the author of the bug steps up, mans up and fesses up. > **[The man who says he gave the Internet ‘Heartbleed’ talks about his mistake](https://www.washingtonpost.com/news/morning-mix/wp/2014/04/11/the-man-who-says-he-gave-the-internet-heartbleed-talks-about-his-mistake/?tid=pm_national_pop)** > > German programmer says Heartbleed was an accident. Is the nature of the industry to blame? Bloomberg reports that the NSA has allegedly known about the bug for a while and has exploited it: [http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html](http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html) I believe it reasonable to question whether the NSA conducted an accurate, proper and comprehensive cost/benefit analysis. ---
**Author:** ![tellyworth](https://avatars.discourse-cdn.com/v4/letter/t/977dab/32.png) [@tellyworth](https://boards.straightdope.com/u/tellyworth)\ **Post date:** [April 11, 2014, 10:26pm UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/35 "2014-04-11T22:26:58Z")
Cloudflare has been [testing the exploit](http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed) and has been unable to use it to steal a private key. Which doesn’t mean no keys were stolen, but at least means that, for certain configurations, it’s not trivial. The’ve put up vulnerable server as a challenge, to see if anyone can steal its keys. ---
**Author:** ![Measure\_for\_Measure](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/measure_for_measure/32/557_2.png) [@Measure\_for\_Measure](https://boards.straightdope.com/u/Measure_for_Measure)\ **Post date:** [April 11, 2014, 10:40pm UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/36 "2014-04-11T22:40:41Z")
> [@tellyworth](#): > > Cloudflare has been [testing the exploit](http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed) and has been unable to use it to steal a private key. Which doesn’t mean no keys were stolen, but at least means that, for certain configurations, it’s not trivial. To be clear: The nature of the bug is explained in [this xkcd cartoon](http://xkcd.com/1354/). Cloudflare notes that hackers can obtain user passwords in this manner: it’s just a lot harder for them to extract private SSL keys: The major problem (and cause of heartbleed) is that the code does not check that this length is the actual length sent in the heartbeat request, allowing the request to ask for more data than it should be able to retrieve. The code then copies the amount of data indicated by the length from the incoming message to the outgoing message. If the length is longer than the incoming message, the software just keeps copying data past the end of the message. Since the length variable is 16 bits, you can request up to 65,535 bytes from memory. The data that lives past the end of the incoming message is from a kind of no-man’s land that the program should not be accessing and may contain data left behind from other parts of OpenSSL. … Previous requests could contain password data, cookies or other exploitable data. Private keys are a different story; due to the way the heap is structured. The good news is this means that it is much less likely private SSL keys would be exposed. ETA: Caveat! There have been reports of a private key being stolen from Apache servers, but only on the first request. This fits with our hypothesis that restarting a server may cause the key to be revealed briefly. Apache also creates some special data structures in order to load private keys that are encrypted with a passphrase which may make it more likely for private keys to appear in the vulnerable portion of the stack. ETA2: So maybe some hacker got lucky _months ago_ with a small number of websites (eg. one SOL website). ---
**Author:** ![Rysto](https://avatars.discourse-cdn.com/v4/letter/r/ecccb3/32.png) [@Rysto](https://boards.straightdope.com/u/Rysto)\ **Post date:** [April 12, 2014, 1:48am UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/37 "2014-04-12T01:48:25Z")
I find arguments based on the behaviour of the heap to be pretty dubious. The problem is that the behaviour of a malloc implementation will vary **greatly** between operating systems. The best that you can say based on CloudFlare’s analysis is that on the processor architecture that CloudFlare uses (probably x86-64), running whatever Linux release CloudFlare uses, using whatever libc version CloudFlare uses (and not replacing malloc with an alternative version like Facebook does with jemalloc), running with the OS configuration that CloudFlare uses (e.g. address space layout randomization would presumably change that argument a lot?), it’s unlikely for private keys to have been leaked. Also, in the of a determined attacker with huge resources and 2 years to play with (i.e. the NSA) they could still catch you in a maintenance window and screw you. Remember, they only have to get the private keys once. ---
**Author:** ![tellyworth](https://avatars.discourse-cdn.com/v4/letter/t/977dab/32.png) [@tellyworth](https://boards.straightdope.com/u/tellyworth)\ **Post date:** [April 12, 2014, 4:08am UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/38 "2014-04-12T04:08:54Z")
> [@tellyworth](#): > > The’ve put up vulnerable server as a challenge, to see if anyone can steal its keys. That didn’t take long: [two people have broken it already](https://twitter.com/EFF/status/454798954115244032). ---
**Author:** ![Measure\_for\_Measure](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/measure_for_measure/32/557_2.png) [@Measure\_for\_Measure](https://boards.straightdope.com/u/Measure_for_Measure)\ **Post date:** [April 12, 2014, 7:33pm UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/39 "2014-04-12T19:33:28Z")
> [@tellyworth](#): > > That didn’t take long: [two people have broken it already](https://twitter.com/EFF/status/454798954115244032). I’d like to sincerely and publicly thank Cloudflare for presenting this challenge. Now we know. ---
**Author:** ![Measure\_for\_Measure](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/measure_for_measure/32/557_2.png) [@Measure\_for\_Measure](https://boards.straightdope.com/u/Measure_for_Measure)\ **Post date:** [April 12, 2014, 8:10pm UTC](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668/40 "2014-04-12T20:10:21Z")
Just to be crystal clear: what can a bad guy do with an SSL key? A bad guy can do the following: [ul] [li]Launch a man in the middle attack.[/li][li]Create a fake version of the target’s website, complete with lock.[/li][li]Possibly intercept traffic between user and target. Or rather if they have intercepted such traffic, they can translate it. [/li][/ul] I’m assuming the bad guy can’t use the SSL certificate to break into the target’s database. Right? (I’m assuming that the target has changed its internal passwords this week. That would be good practice and standard practice, right? ) [Previous page](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668.md?page=1) [Next page](https://boards.straightdope.com/t/heartbleed-a-serious-security-bug-what-should-i-be-doing/685668.md?page=3)