Heartbleed

https://www.schneier.com/blog/archives/2014/04/heartbleed.html

by crumbly • 12 years ago

296 158 12 years ago

schneier.com

0x006A• 12 years ago

Why is his server still vulnerable?

dfa03• 12 years ago

He's running on a Windows box?[IIS]

Rynant• 12 years ago

IIS doesn't use OpenSSL though; it uses CredSSP http://technet.microsoft.com/en-us/library/cc755284(WS.10).a....

personZ• 12 years ago

Windows doesn't use OpenSSL, and Schneier's host is using Apache. I assume that he must not have direct control of his host or for some other reason cannot immediately upgrade/restart.

pvnick2• 12 years ago

At this point it's safer to say that an intelligence agency is responsible than that they aren't responsible. This is precisely what Schneier, Greenwald, et al. mean when they say that the NSA tactics degrade the security of the overall internet architecture. It's incredibly dangerous.

venomsnake• 12 years ago

I personally incline toward - memory safety in C is hard. We have had enough of those bug pop on their own to need encouragement. Whether interested parties knew of it and use it as a key towards all you can eat intelligence buffet is another story.

natdempk• 12 years ago

Memory safety in C is hard, but this bug, a memcpy with a user-supplied, unchecked length? I mean this is stuff that I learned about in my first serious class that involved C, and it wasn't even security related. C is a language where you code defensively at almost all times, yet this was ignored in the SSL implementation, a project which is based around communicating with a user? This is the situation where you really can't trust things like lengths. Either its incompetence or shilling, both of which are harrowing.

ahomescu1• 12 years ago

There is no proof in either direction. It's safer to just say nothing at all.

jessaustin2• 12 years ago

"Safer" is an interesting adjective: its meaning depends on your threat model. Are you more worried about underestimating the already-tarnished honor of a secretive federal agency, or about being screwed over by that same agency? I personally care more about the latter.

rtpg2• 12 years ago

How can you make such a claim? Do you have any proof that they were involved with this specific bug?

I get that the NSA is after us but when you consider that the bug is of the exact same class as a bug every C programmer has ever made in their career, it seems probable that it could have happened on accident. Where do you see the malicious intent?

mietek• 12 years ago

Why do heartbeats need payloads?

3pt14159• 12 years ago

The NSA has two mandates. First, it is to ensure that Americans are using secure communication channels. Second, it is to collect data. When these two things come into conflict they have the authority to make a decision. For centralized communication channels, for example, they will often help beef up security in exchange for the ability to wiretap.

If this bug was not caught by the NSA, then they are incompetent, something that I've rarely seen levelled at them as of late, but it is possible. If this bug was perpetrated by the NSA, then they are evil because they are exposing Nato and other allied countries to foreign attacks and corporate espionage.

Given the stakes, what they've said in the PRISM slides, and their history, I'd say evil is more likely than incompetent.

pvnick2• 12 years ago

We know from the NSA's own files that they pour lots of money into programs that specifically introduce bugs like this [1]. Do the current batch of leaked documents outline this exact vulnerability? No. Does it perfectly fit the model of what the NSA's own files say they're doing and therefore make it a high-likelihood explanation? I think so. At the very least the assumption that an intelligence agency, such as NSA or GCHQ, is responsible is a useful way of thinking about the kind of adversaries one faces with this type of software.

[1] http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryp...

clef2• 12 years ago

If the NSA is all knowing as everybody seems to think, why aren't all criminals in jail by now?

lmm• 12 years ago

We have no proof, but as such we have to assume that it's an NSA-directed compromise and take appropriate precautions, unless and until we have proof otherwise. That's why the NSA's actions really hurt.

a3n• 12 years ago

It doesn't matter whether they created it. If your operations would suffer from the NSA having had access to this anywhere between 1 day and two years ago, then you have to assume they took advantage of it whether they created it or not, and you have to execute any damage control and mitigation procedures that you've created. I.e. assume your data has been read and used, and act accordingly.

smtddr• 12 years ago

Nah, I am extremely pro-Snowden & extremely anti-NSA... but I'm also a person that enjoys programming in C.

C is hard. I really think this was just a bug. What _is_ possible though is that the NSA knew about this bug since awhile back and kept it secret. But then if they knew about the bug, why was nasa.gov vulnerable? I would not expect any .gov domains to be vulnerable unless to create plausible deniability - but this kind of conspiracy logic has no end.

AYBABTME• 12 years ago

What's critical about nasa.gov? It's just a marketing facade. Not patching it means nothing.

I'm not saying that NSA did/didn't do X. Just that the above about .gov domains is not a valid argument. Intelligence gathering trumps trivial service to citizens.

cliveowen• 12 years ago

More on the vulnerability from cryptographer Matthew Green:

http://blog.cryptographyengineering.com/2014/04/attack-of-we...

rossjudson2• 12 years ago

I am curious about which static code analysis tools pick up this problem. Could it have been found automatically by Coverity, for example?

BudVVeezer• 12 years ago

We tested most of the major ones at work on the faulty code, and only PC-Lint caught the issue.

TomGullen• 12 years ago

Just a question (and I don't know too much about this). Is there any chance that certificate authorities who give out warranties could actually have to pay out on them now? Do any of them use OpenSSL?

hadoukenio• 12 years ago

I think the warranty only covers losses that occurred during the use of the certificate. If it wasn't limited liability, Heartbleed could have caused a "Lehman Brothers" style default for all CAs.

danielweber6• 12 years ago

Without looking at the specifics, the CA can't be held responsible for you leaking the key yourself.

Or do you mean if the CA companies themselves were compromised? That's a big separate issue. Even if the web process is the one that generates the keys (I'm skeptical, but it's possible), any keys made that way would quickly be moved out memory, unless they were made that day.

efficientarch• 12 years ago

Also see this explanation from Troy Hunt, which hasn't made the front page. https://news.ycombinator.com/item?id=7558597

yiedyie• 12 years ago

TL, DR:

Troy Hunt: ”The Heartbleed bug itself was introduced in December 2011, in fact it appears to have been committed about an hour before New Year’s Eve (read into that what you will). The bug affects OpenSSL version 1.0.1 which was released in March 2012 through to 1.0.1f which hit on Jan 6 of this year. The unfortunate thing about this timing is that you’re only vulnerable if you’ve been doing “the right thing” and keeping your versions up to date! Then again, for those that believe you need to give new releases a little while to get the bugs out before adopting them, would they really have expected it to take more than two years? Probably not.”

krallja• 12 years ago

Debian squeeze (oldstable) is not vulnerable, because it's still running 0.9.8o-4squeeze14.

0.9.8o was released 2010-06-01, almost 4 years ago!

bcohen5055• 12 years ago

"At this point, the odds are close to one that every target has had its private keys extracted by multiple intelligence agencies" Any proof of this?

dfa03• 12 years ago

If it was your sole purpose in life to bust dams, and then suddenly you were given a cache of unlimited dynamite...what would you do?

To the point, when the nature of a thing is to foo and you remove all obstacles from that event, expect positive feedback...and lots of it.

danielweber6• 12 years ago

It's bullshit.

I'm 100% positive that many targets have had their keys extracted, but it's hard-to-impossible for the attacker to choose what fragment of memory the server returns, and it depends heavily on the server in question. What works against nginx won't work against lighttpd or apache.

I hit a site I control repeatedly yesterday and couldn't even get any common byte-arrays in common across hundreds of connections.

Of course, as good practice, all organizations should treat their keys as compromised and issue new ones.

Also, his "it leaves no trace" is a problem. It's trivial to recognize the traffic pattern.

kgo• 12 years ago

Well the odds are non-zero. If you're worried about intelligence agencies harvesting your private keys, any odds above 0 is close to 1.

clarkevans• 12 years ago

Even if we generate a new key pair and replace our certificate, aren’t we still vulnerable to MIM attacks if someone had downloaded the old private key and use the old certificate?

ibotty• 12 years ago

until it's revoked.

ig1• 12 years ago

Yes. Certification revocation doesn't work in MITM scenario because of the way it's implemented in every major browser:

http://news.netcraft.com/archives/2013/05/13/how-certificate...

danielweber6• 12 years ago

Also, how does issuing a new certificate work with certificate pinning, whether tack.io or built into the browser?

I was working on a standalone certificate checker last year but couldn't figure this one out.

MichaelGG• 12 years ago

Doesn't browser pinning usually pin to the CA?

higherpurpose• 12 years ago

That's why it's so vital for everyone to implement Perfect Forward Secrecy. Yes, it's a little late for that now in regards to this bug, but who knows what others bugs like this will be discovered in the future. Let's at least not make the same mistake twice, by not taking advantage of PFS, which could've prevented most of the damage from Heartbleed.

Perseids• 12 years ago

As much as I'm a fan of Perfect Forward Secrecy, it does not protect you against MITM with old certificates.

yp_master• 12 years ago

                             Schneier.com Has Moved

   As of March 3rd, Schneier.com has moved to a new server. If you've used a
   hosts file to map www.schneier.com to a fixed IP address, you'll need to
   either update the IP to 204.11.247.93, or remove the line. Otherwise,
   either your software or your name server is hanging on to old DNS
   information much longer than it should.

Ok, how should I "authenticate" that the site at the new address is the "real" one?

I know, I'll use OpenSSL and HTTPS!

mrfusion• 12 years ago

So if I have a site that doesn't use SSL, am I still affected? I'm still trying to make sense of all of this.

apawloski• 12 years ago

No, if you're not using OpenSSL your site will not be vulnerable to an OpenSSL bug.

But if your site transmits or receives anything that a third party shouldn't see (hint: it probably does), you should start using SSL.

atonse• 12 years ago

I would rather say...

If you're not using SSL right now, there's no rush to upgrade, but do it anyway while this is in the forefront because when you do use SSL one day on your server, you might forget that you had this old version of OpenSSL.

fidotron9• 12 years ago

One of the things I'm taking from this episode is just how worthless a lot of prognostication about security by a load of "experts" on the internet is, especially of the "trust us to get it right" variety.

Frankly, their whining about how hard crypto is is partly responsible for the monoculture we have. Yes, it's difficult (more so in protocol than implementation), but they are so offputting to new people coming into the field it is insane.

Clearly OpenSSL dev is broken, at least partly because everyone assumes everyone else is auditing all 300k lines of it, but also I can't help wondering if this calls for stronger component isolation within cryptosystems. For example, protocol implementation, encoding and decoding seem like they should all be totally isolated, so a disaster like this doesn't mean you could be leaking information from the rest of the system. I imagine many a HSM vendor has been quite pleased by this news.

dvanduzer3• 12 years ago

There's a few different "just trust us" mentalities, but I've become more comfortable with the "don't roll your own if you missed the first 10 minutes of the lecture" worldview.

Separating algorithm from implementation seems like it shouldn't be so difficult, but retrospect is a great teacher. So now we have approaches like NaCl, where the algorithms are designed to be hard to implement badly. And we have projects like LibTom, which aims to implement existing algorithms clearly. Both seem to be enjoying varying degrees of success.

tptacek12• 12 years ago

NaCl is designed to be user-proof. Part of its appeal is that it uses state-of-the-art primitives and constructions, but the reason it's so widely recommended, and the thesis behind its design, is that it's hard to misuse.

The same isn't true of LibTomCrypt.

Use NaCl. Be very, very careful with LibTomCrypt.

mikeash10• 12 years ago

This is (I hope) a once-in-a-lifetime incident, so we have to be careful not to extrapolate it too hard. On the other hand, it's seriously big deal. Overall, it seems to strongly challenge a couple of important assumptions.

As you say, it's a strong challenge to the mantra of "never implement your own crypto". I think (think) it still holds for the crypto primitives. If you're reimplementing AES you're probably doing it wrong. But the protocols? I'm not so sure now. Common wisdom seemed to be that if you implement the protocols yourself you'd screw them up, and you should stick with tried-and-true existing implementations. Now it's apparent that "tried" doesn't have to imply "true". Something being used by millions of people for years doesn't prevent it from having a huge vulnerability for years. Are your odds better or worse rolling your own? I'm not so sure now.

Consider Apple's "goto fail" bug, for example. Among a lot of other stuff, they caught some criticism for reimplementing TLS instead of just using OpenSSL. Well, if they had used OpenSSL instead, it turns out that they would have been shipping an even more serious bug for even more time.

It's also interesting to me how it challenges the idea of encrypting stuff by default. For years, people have been saying that as much traffic as possible should be encrypted, even unimportant stuff that nobody cares about. By doing that, the idea goes, using encryption isn't suspicious and you force attackers to spread out their resources. If only a small amount of traffic is encrypted, attackers can focus just on that traffic. Accordingly, a lot of sites that didn't really need it enabled SSL or even required it, including my own. By doing this, a lot of them inadvertently made things much much worse. A site that's only accessible over HTTP is much better off than a site that's accessible over HTTPS but vulnerable to heartbleed. I don't think the general idea is wrong, but it certainly gives me pause, and I think more consideration has to be given to the increase in attack surface you take on when you enable encryption.

In any case, I really hope we see some new crypto projects come out of this, or more resources put into existing OpenSSL alternatives.

ISL2• 12 years ago

This is (I hope) a once-in-a-lifetime incident, so we have to be careful not to extrapolate it too hard.

Don't bet on it.

Shish2k2• 12 years ago

Even though this hole is huge, the ratio of attack-surface-exposed to security-gained from SSL is still in general worth it; you'd be throwing the baby out with the bathwater to disable encryption entirely IMO

For comparison, would you avoid having a web server (or roll your own) because of CodeRed?

dvanduzer3• 12 years ago

There's quite a lot of energy going into crypto outside of the OpenSSL world.

If you're interested in ubiquitous crypto (using standard primitives, and mirroring standard protocols), the Telehash Cipher Sets are a great place to start: https://github.com/telehash/telehash.org/blob/master/cipher_...

There are a surprising number of crypto-related implementation difficulties in all the language ecosystems (even if all you want to do is wrap OpenSSL) that have nothing to do with the "hard" parts of the algorithms.

skybrian• 12 years ago

The good news (sort of) is that it's an ordinary buffer overflow attack. We've known that these are a problem for decades and we've known how to check for them automatically for decades. Even in C's niche there are research prototypes for safe C-like languages. And yet there seems little effort to make them production-ready and deploy them; what kind of market failure is that?

I think this is the final nail in the coffin for the ideas that "many eyes make all bugs shallow" or that code review alone by "experts" is enough to eliminate even the simplest of bugs. Use static analysis or go home.

There are plenty of other ways to screw up with crypto but they don't pass out the server's private keys just like that.

steveklabnik3• 12 years ago

And yet there seems little effort to make them production-ready and deploy them; what kind of market failure is that?

At least we have Rust...

rst2• 12 years ago

Only sort of.

The main technical point of Theo de Raadt's "exploit mitigation countermeasures" post is that even when the infrastructure it's running on is trying to add safety checks, OpenSSL will often neuter them. The specific example was the exploit mitigations in OpenBSD's malloc, which are neutered for OpenSSL because (for dubious stated reasons) it insists on wrapping the system malloc with its own caching variant. The same would apply, of course, to more straightforward measures like a malloc() which just cleared out the returned memory before turning it over to the app.

And this isn't the only thing about the OpenSSL codebase which seems likely to frustrate attempts at analysis. (Heck, the whole "forest of #ifdefs" thing has got to be at least a bit of a stumbling block.)

Theo's email here: http://article.gmane.org/gmane.os.openbsd.misc/211963

HN discussion here: https://news.ycombinator.com/item?id=7558199

tptacek12• 12 years ago

Surely, Nigel, if you'd just implemented your own encrypted transport, everything would have worked out great. Look how well that worked for Cryptocat.

The most consistent complaint about OpenSSL is that it is developed amateurishly (I think it's more complicated than that, but "amateurish" is a fair summary of the critique). Your response seems to be, "double down on amateurish!"

PS: The only reason you know about heartbleed is that one of the self-proclaimed "experts" found it for you. Neel Mehta is an insider's insider.

fidotron9• 12 years ago

Anyone would say you stand to benefit from security remaining some sort of priesthood activity or something.

Diversity of implementations is a good thing, for the simple reason the number of people an individual vulnerability could expose would be that much smaller.

drewcrawford2• 12 years ago

Ok, I'm going to take the counterpoint on this.

Heartbleed, and "goto fail" are bugs that any competent C developer could have found. You, me, the muffin man, the NSA, a bright undergraduate student. Anyone. These aren't vulnerabilities that you read about in a crypto journal. They are basic implementation bugs.

So why weren't they found by amateurs? (Well, perhaps the premise is false. Perhaps they were found by amateur attackers.) However I submit to you if true it is because people who are actually experts in cryptography do not generally spend their time looking for dumb implementation bugs. I'm sure some do, but many don't. Which is understandable--we want those people looking for weaknesses in AES or curve25519 or something.

Meanwhile we have a culture of abstinence-only crypto education, where everything crypto touches is a forbidden land that we shame any ordinary software developer for venturing into. Nobody found this bug because ordinary developers aren't there to find it. They're not there because they're told to leave.

You suggest "double down on amateurish" facetiously but I claim that amateur hour would have actually caught these two bugs, because any amateur can see them. Maybe it would have created more bugs, maybe not, but I think it would have stopped these two early.

What I think we need to do, and what we should have done a long time ago, is recognize that abstinence-only crypyotgraphy doesn't work. We need to define levels of risk. Writing your own crypto algorithm is Threat Level Red. Implementing a strong one from a spec is Threat Level Yellow. Implementing a high-level authentication scheme like TLS from a spec is Threat Level Green. Porting OpenSSL to a new architecture is Threat Level Blue.

Abstinence-only crypto education doesn't recognize that some people are going to do crypto anyway. It also doesn't recognize that "not enough eyes" is a threat model that objectively produces THE most serious vulnerabilities we have faced in recent years. Putting all our eggs in OpenSSL and telling ordinary developers to use it and not ask questions literally burned down the internet. I don't know what kind of bad scenario we were trying to avoid, but the one that actually happened was worse.

Some type of risk-aware model encourages people to get involved in a skill-appropriate way. That needs to be the goal of the crypto community right now; to capture the energy from software developers interested in cryptography (particularly due to recent world events) and do something useful with it; not turn them away and say "nothing to see here".

area51org2• 12 years ago

"Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.

No, it's not. If you asked me — I was a CISO not many years ago — I'd call this an 8. Schneier means well, but he has a tendency to exaggerate. (Here is an example of him suggesting that SOAP and other web services never be used because they "sneak" through HTTP and are therefore inherently insecure: https://www.schneier.com/crypto-gram-0006.html#SOAP)

A 10 would be a case where a bug was not easily patched, and gave complete control of servers to any interested script kiddie. Thousands or millions of web users would have had enough information for credit card and identity theft to be acted on before the hole could be plugged.

This is not that case. And it's certainly not an "11". Most vital websites have either already been patched or are about to be.

We can now keep calm and carry on.

scott_karana• 12 years ago

Heartbeep did, in theory, allow for millions of web users to have their credit cards, passwords, addresses, social security numbers, tax filings and more to be compromised.

Worse than "only in danger until patched", retroactively stored traffic is vulnerable if, like many sites, Perfect Forward Security wasn't used.

If the NSA took advantage of this at all, their logged traffic has become very useful...

orthecreedence• 12 years ago

I'm going to have to go ahead and sort of disagree with you. A security library, specifically doing crypto, that is installed/embedded/used everywhere that trivially leaks plaintext data remotely to anyone who comes knocking (including passwords, keys, CC numbers, etc) is a compete failure.

Sure, it could hand out shells into a remote system, or hell it could launch a bunch of nuclear rockets as well...that would be very bad. But you seem to miss the point that perhaps someone's password to their shell (or maybe a nuclear launch code) is going over the wire and is intercepted...by a hostile government agency, or a 13 year old playing with a python script. There are endless, devastating scenarios one can think up caused by such a critical bug in the very fabric of the secure communication of the internet.

This is a pretty big deal.

btbuildem• 12 years ago

You're right - but I think a rating of 11 should indeed be reserved for a bug that does launch nuclear rockets while handing out root shells.

wiredfool• 12 years ago

By my understanding, there's about 1 checkbox that this doesn't tick: remote code execution. It's widespread, anonymous, and easy to exploit.

area51org2• 12 years ago

But not difficult to patch, which is a critical factor here.

acqq• 12 years ago

myforwik writes:

http://arstechnica.com/security/2014/04/critical-crypto-bug-...

"Even 11 is an understatement. Remember the servers involved have potentially been leaking their private key for their certificate! This means anyone can 'fake' being them.

It is not enough to do new certificates. All of the old certificates could now be used for man in the middle attacks! 2/3rds of the Internets certificates potentially need to be blacklisted! This is a MAJOR disaster.

It is unfeasible to blacklist such a large amount of certificates - as every device requires a list of all blacklisted certificates. This means all of the major CA's are going to have to black list their intermediate certificate authorities, and start issuing all new certificates under new CA's. This means even people who weren't effected will probably have to have their certificates blacklisted.

In short EVERY existing CA used on the internet may have to be black listed, and every single SSL certificate re-issued.

IMO SSL/TLS is now completely broken. The number of potential certificates that have been exploited and that could now be used for man in the middle attacks could be in the millions..... the list of black listed certificates will be in the millions and/or the number of blacklisted sub certficate authorities is probably going to be 10,000+. Vendors already hate just including one or two items on the blacklist, let alone this number of items.... "

It's not actually 2 thirds of the Internet, but it can be that the effects can be really bigger than most people imagine on the moment. Either the massive blacklisting or ignoring the period of potential exposure.

Hopefully all this can result in the push to change some of the principles of certificate verification. And maybe a different approach to OpenSSL development.

feelstupid• 12 years ago

Forgive my naivety here, but is there any way to tell which sites over the last 2 years I/we have used that may require new passwords, and whether they've been fixed?

I'm kinda looking at a site that lists the major sites (Banks, Socials, Shops, etc) that shows a status on whether you're fine / should change password / await fix before change password)

CanSpice• 12 years ago

Yes. All of them.

Seriously, it's easier to just change all of your passwords than to hunt down a list (that will be incomplete and give you a false sense of security), cross-match against servers you might have an account on, then change their passwords.

Just change them all and be done with it.

The "whether they've been fixed" part is a little tougher, because that lets you know when you should change your password. General sentiment I've been seeing is give it a week for everybody to fix their stuff (even this might be a little long) and then change your passwords. If a given site says either "we weren't affected, here's why" or "we've patched our stuff, we're all good" then you should change your password on that site ASAP.

jeff3032• 12 years ago

When would be the optimal time to perform these password changes? I am assuming that not every affected site has been patched yet, and it would be pointless to change the password, and log in, before they have fixed the problem.

jl62• 12 years ago

Interesting point for me is that those who serve over HTTP only are not vulnerable, which I think is a good case study in the risk of complexity. A lot of security experts have been calling for HTTPS everywhere, on the basis that it is low cost. Clearly there is a cost to the extra complexity, and in this case a bug in the security layer that results in a worse situation than if there had been no security layer at all.

awj• 12 years ago

Interesting point for me is that those who serve over HTTP only are not vulnerable

...yes they are. You don't even need remote private key disclosure to MITM an http-only server. The way HTTP digest is written means you either store all passwords in a retrievable form or drop down to basic auth where anyone capable of base64 decoding can read all passwords.

This situation is by no means worse than if everyone had just used plain HTTP.

jl62• 12 years ago

MITM is only one type of attack, which is largely irrelevant to public sites serving non sensitive information. But server memory is always private and could assist in escalation of a further attack.

subleq• 12 years ago

It is worse than plain HTTP, actually. Heartblead allows an attacker anywhere on the internet to read out memory from your server. This is worse than plain HTTP in two ways:

- With plain HTTP, the attacker would have to be in a MITM position to intercept traffic. With Heartblead, he can read traffic he wouldn't normally have access to from the server's memory.

- There may be secrets in memory that would never even be sent over the network that are now accessible. For example, if running a web app in the same process doing SSL termination, private keys such as Django's SECRET_KEY may be available. Under certain situations, knowledge of the SECRET_KEY can effect remote code execution.

In short, Heartbleed gives the entire world the ability to read memory from your server. This is much worse than an HTTP MITM.

mikeash10• 12 years ago

Here's an example where Heartbleed is much, much worse.

I run an HTTP-only server that's read-only for the public. However, I have an admin interface that lets me log in and make changes to the site. For example, a WordPress blog.

Now, let's say that I run the server at home and I'm careful only to log in as an admin when on the home LAN. This is perfectly secure even though I'm only using plain HTTP.

If I decided to instead serve HTTPS, the heartbleed vulnerability means that anybody could potentially hijack my sessions, steal my passwords, and edit the site. Depending on how much password reuse is going on, they could own the entire box, or just put malicious code on the site for all my visitors to run into.

andreasvc2• 12 years ago

That comparison is off. HTTPS secures communications; this bug exposes memory, you still want the first without the second and HTTP doesn't offer it. Minimizing complexity is a worthwhile goal but definitely not the only one since otherwise we could simply opt not to have communication that needs to be secured at all.

mikeash10• 12 years ago

Sometimes you don't actually care about the first but still care about the second. In cases like that, HTTPS with heartbleed makes you much worse off than plain HTTP.

rbanffy• 12 years ago

On the XKCD [0] you can find a spoof of the Tears in rain soliloquy. I never imagined it was rewritten on the night before shooting by Rutger Hauer.

[0] https://xkcd.com/1353/

[1] https://en.wikipedia.org/wiki/Tears_in_rain_soliloquy

fixermark• 12 years ago

Request for clarification from those who understand the bug's workings:

The memory it can expose is limited to that visible to the process using openssl, right? Or does the bug reside low enough in the kernal stack to disregard memory protections?

mattgreenrocks• 12 years ago

The memory it can expose is limited to that visible to the process using openssl, right

Yes. Only that process.

nzp• 12 years ago

Eh, I remember how about a month ago when that recent GnuTLS bug was found the almost dominant sentiment on HN was along the lines of "how come anyone is using GnuTLS instead of OpenSSL", "GnuTLS codebase is horrible, use OpenSSL", "the guy maintaining GnuTLS is an idiot, use OpenSSL", "OpenSSL has more expert eyes on it", etc. Although I prefer OpenSSL (for no particular reason), this all seemed so obviously stupid and shortsighted, not to mention some of it factually wrong. And what do you know, a month later we get an order of magnitude worse bug in OpenSSL which was also probably an order of magnitude easier to detect. I made a comment[0] then along that line, thinking to myself that I'd really hate if I got to say "told you so" but that unfortunately I probably will get the chance. I didn't think it would be this bad though.

[0] https://news.ycombinator.com/item?id=7346879

jypepin2• 12 years ago

And that's why every single login system should have two-factor auth - I started using google's authenticator app for my google and github account and it works just great. I wish I could use it for every account I have.

eridius• 12 years ago

SSL is not login.

jypepin2• 12 years ago

Sorry, I didn't mean to say that TFA was the solution, but I think login info leak is one of the consequences of heartbleed, right? So my point was just, at least with TFA, the risk of having your accounts stolen is reduced.

tptacek12• 12 years ago

There is virtually no useful software vulnerability for which you can't conjure up a compelling-sounding narrative of deliberate introduction (or "bugdoor"). It's like numerology. So you should be wary of people insinuating about bugs.

What makes Dual_EC so compelling to experts is the "Nobody but us" nature of the flaw: the bug is cryptographically limited to a small number of actors. FedGov buys hundreds of millions of dollars of COTS gear with OpenSSL embedded, and this bug is so simple that middle-schoolers are exploiting it. You shouldn't even need to ask if it was deliberate.

dllthomas9• 12 years ago

One question - this keeps talking about attackers being able to "read all of memory." Does anyone know whether that's limited to the process that is running OpenSSL code?

facepalm• 12 years ago

Is there really a point in changing keys and passwords? It seems to me that if an attacker got the passwords, I should assume they already installed a root kit on my server?

I'm honestly not sure how to react. I'm not really a sysadmin, but I have a server online.

I suppose I could start a new server, but how can I be sure that the provider has already patched all their holes? If they've been hacked, maybe the images they use for preparing new servers have been compromised, too? Might be better to wait a little before restarting everything from scratch?

Heartbleed

Related Stories