Live data from Hacker News

The Heartbleed Bug

heartbleed.com

291–300 of 547 posts

Re: The Heartbleed Bug

#291
post #247
post #49

Holy shit. That seems worse than the debian openssl debacle. If i got that right ALL openssl private keys are now potentially compromised. I hope vendors push fixes soon, and then I guess I'm busy for a few days regenerating private keys.

Oh it's even worse , basically every secret you had in your server processes' RAM was potentially read in real-time by an attacker for the last 2 years.

Isn't there any memory protection on Linux? Something running as www-data shouldn't be able to read the ssh-server's RAM?

So it's bad, but it's not that bad unless something exposing this bug (webserver with ssl, vpn, or other service) runs as root?

Re: The Heartbleed Bug

#292

Earlier quoted context omitted.

>no amount of security is worth a 1000% performance hit Yes it is. Most of the applications I use take roughly 0% of my processor's capacity. I can spare a multiple like that outside of a few hot loops. Saying 10x slowdown isn't worth it is like saying no one would ever compute on a phone. Also random BS benchmark http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... says haskell is at least half as fast as…

> Most of the applications I use take roughly 0% of my processor's capacity. We're talking about a server-side vulnerability in OpenSSL here, not applications running on your personal computer. Roughly speaking, making your server code twice as slow means it will cost you twice as much money to run your servers. Of course, that depends a lot on what exactly you're doing and is obviously not always true... but OpenSSL…

> If OpenSSL suddenly became twice as slow, it would cost a lot of people a lot of money.

All other things being equal, yes. But responding to security incidents also costs a lot of people a lot of money.

Re: The Heartbleed Bug

#293

We use openvpn. Does that need to be updated?

As far as I can tell, openvpn with TLS authentication is vulnerable as it just uses the usual TLS suite. If you use PSKs or the (mis-named?) --tls-auth PSK additional MAC, then you are only owned if one of your own legitimate nodes revealed the PSK (or was coopted into performing this attack) in which case you're already owned.

Re: The Heartbleed Bug

#294
post #218

Earlier quoted context omitted.

I'd disagree about C++. In my experience, the only things it adds is (1) a false sense of security (since the compiler will flag so many things which are not really big problems, but will happily ignore most overrun issues), (2) lots of complicated ways to screw up, such as not properly allocating/deleting things deep in some templated structure, and (3) interference with checking tools - I got way more false positiv…

I'd disagree with your disagreement ;-) C++ has constructs that let you build safer and more secure systems while maintaining good performance. You can write high performance systems without ever touching a raw pointer or doing manual memory management which is something that you can't really do in any other language. Yes, you need to trust the underlying library code which is something you have to do for pretty much…

I second this point. The keyword here is "modern" C++, which encourages people to write shared-memory symantics, and to create strategies that make it impossible to screw up.

"New" is a thing of the past, along with the need to even see T *.

These days good code in C++ is so high-level, one almost never sees a pointer, much less an arbitrarily-sized one. This is of course unless you're dealing with an ancient library.

Another thing of importance:

If you're working with collection iteration correctly (which tends to be the basis for a lot of these out of bounds errors), there is no contesting the beginning offset, or the end offset - much less evaluating whether that end is in sight. Even comparisons missing stronger types showing "this thing is null terminated vs that is not" can be eliminated if you just create enough definitions for the type-system to defend your own interests. If you're coding defensively, these shouldn't even be on the menu. One buffer either fits in the other for two compatible types, or you simply don't try it at all.

It'd be amazing what standard algorithms can leave to the pages of history, if they were actually put to good use.

Python has some nice high-level concepts with their "views" on algorithmic data streams that show where modern C++ is headed with respect to bounds checking, minus the exceptions of course :)

Re: The Heartbleed Bug

#295
post #48

Earlier quoted context omitted.

Worse, it's retroactively unfixable: Even doing all this [revoking certs, new secret keys, new certificates] will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. So it would be a good idea to change all your passwords to critical services like email and banks, once they have issued new certs and updated their openssl.

Worse, it's retroactively unfixable That's slightly misleading. Every private key disclosure leads to decryption of past traffic unless forward secrecy is used. However, if you switch to a fixed version of OpenSSL now , then an attacker cannot retroactively exploit this bug even if they have recorded all your past traffic, because exploiting the bug requires a live connection. (Of course, this only applies to attacke…

I think what was meant is that since exploiting this bug leaves no trace, you should automatically consider every master key ever loaded to a vulnerable OpenSSL application to be already compromised. As nothing says this is the first discovery of the bug, one should consider that the black hats have already been exploiting this for long before the first public disclosure.

Re: The Heartbleed Bug

#296
post #221

Earlier quoted context omitted.

> C and other languages without memory checks are unsuitable for writing secure code I vehemently disagree. Well-written C is very easy to audit. Much much moreso than languages like C# and Java, where something I could do with 200 lines in a single C source file requires 5 different classes in 5 different files. The problem with C is that a lot of people don't write it well. Have you looked at the OpenSSL source? It…

>The problem with C is that a lot of people don't write it well. There are languages that make it very very hard to write bad code. Haskell is a good example of where if your program type-checks, there's a high chance it's probably correct. C is a language that doesn't offer many advantages but offers very many disadvantages for its weak assurances. Things like the Haskell compiler show that you can get strong typing…

> Haskell is a good example of where if your program type-checks, there's a high chance it's probably correct.

For a value of 'correct' that includes "uses all available memory and falls over".

Re: The Heartbleed Bug

#297
post #291
post #247

Earlier quoted context omitted.

Oh it's even worse , basically every secret you had in your server processes' RAM was potentially read in real-time by an attacker for the last 2 years.

Isn't there any memory protection on Linux? Something running as www-data shouldn't be able to read the ssh-server's RAM? So it's bad, but it's not that bad unless something exposing this bug (webserver with ssl, vpn, or other service) runs as root?

It can only access memory of the process running openssl. So if you got nginx in front of your webprocesses they are protected. However anything in the nginx process is accessible (e.g certificates).

Re: The Heartbleed Bug

#299

I think the summary is a bit too sensationalistic in terms of what the actual security implications are: The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. Yes, while that's true, it's not a "read the whole process' memory" vulnerability which would definitely be cause for panic. The details are subtle: Can attacker access o…

It's not hard to screen what's returned for chunks that look like they could be keys (you know the private key's size by looking at the target's certificate, you know it's not all zeros, etc.) and then simply exhaustively check chunks against their public key.

I just looked at one of my running apache processes, it only has 3MB of heap mapped (looked at /proc/12345/maps). That's not a whole lot of space to hide the keys in.

Re: The Heartbleed Bug

#300
post #227
post #211

Earlier quoted context omitted.

>Additionally, although the parsing portions of OpenSSL need not deal with the hardware directly, the crypto portions do. So your memory-safe language needs some first-class escape hatch to unsafe code. A few of them do have this, others not so much. For the other points there is some debate, but don't most serious languages have a C FFI?

OpenSSL and similar libraries spend most of their time processing short packets. For example, encrypting a few hundred bytes using AES these days should take only a few hundred CPU cycles. This means that the overhead of calling the crypto code should be minimal, preferably 0. This is in part what I meant by "first-class". Perhaps I should have written "zero-overhead" instead. I googled around just now for some bench…

Lua being on top shouldn't be surprising. Its entire purpose is to call into (and to be called from) C, and this case has been highly optimized.
Post reply on HN