3

This question already has an answer here:

From what I gather you need local memory based access correct to even access the private key? Is all this talk and worry of "Was I hacked?!" "Heartbleed just made you full hackable" ect... really over exaggerating the issue?

For example I run some pretty big websites using SSL Certs for HTTPS. Am I really remotely exploitable to where everyone can see plain text passing?

marked as duplicate by Xander, TildalWave, Polynomial, scuzzy-delta, Eric G Apr 10 '14 at 2:08

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Are your servers running a vulnerable version of OpenSSL? What do you mean by remotely exploitable? Do you mean "remote code execution"? Basically anything in memory of the web server process could theoretically be leaked. I've seen people claiming they were able to capture hundreds of username/password combinations from yahoo mail in minutes. Sounds like a big deal to me. I haven't seen analysis on how long it would take to get a private key though. – mikeazo Apr 9 '14 at 19:40
  • Yes, it is remotely exploitable, everyone can get random data (possibly session cookies, source code and maybe even SSL keys). I know someone who was able to obtain thousands of Yahoo passwords in a short time. A client and server PoC can be found in github.com/Lekensteyn/pacemaker – Lekensteyn Apr 9 '14 at 19:44
6

The whole heartbleed story has gone way beyond sanity, for sure.

The bug is real and can be a serious threat to any server. However, the bug is no more serious than all other "buffer overrun" attacks, and arguably less serious than write overflows, which can more easily lead to hostile server hijack. You can have a list of reported security issues for OpenSSL on this page. None of them triggered such a panic as the one we are currently witnessing; yet some were of the "remote code execution" kind, technically much scarier than this heartbleed canard (but without the nifty logo).

The IT industry, as a whole, has come up with a strategy with handling that kind of bugs. It is called "apply the damn security patches from the OS vendor". This strategy is not ultimately elegant, but it works. There is no reason to single out this bug and award it a special treatment, as if it was a new kind of thing (it is not) or exposed to especially dire circumstances (it does not -- its consequences are within the normal range of security holes).

The only benefit of this pandemonium is that it shows who does his job properly. When a panicked sysadmin asks whether he should apply the fix right away and/or reset all his passwords and/or kill his dog (just to be sure), he implicitly admits that he does not usually apply security patches, or at least not promptly -- and that is the problem.

  • 2
    Most of the OpenSSL advisories are either not really practical or "just" cause a DoS. In my opinion Heartbleed is pretty severe as it is quite stealthy and 100% reliable (in the sense that you always get some random data back). – Lekensteyn Apr 9 '14 at 21:17
  • 1
    Well, not really: you get a buffer overrun, so the server will read whatever bytes are there. But this can fall in an unallocated page, triggering a page fault and thus a crash of the server process. Thus, it is not 100% reliable, and neither is it 100% stealthy. – Tom Leek Apr 9 '14 at 21:59
  • 1
    There is no buffer overrun (unchecked length), the large allocated memory is just not cleared. That is why interesting memory (i.e. nonzero bytes) show up when a program is running for a longer time (like webservers or the links client). – Lekensteyn Apr 9 '14 at 22:04
  • Nevermind, I confused the alloc for the target with the source. – Lekensteyn Apr 9 '14 at 22:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.