Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Heartbleed Bug

heartbleed.com

Post reply on HN
Print view View original

201–210 of 547 posts

Re: The Heartbleed Bug

#201

Post by sakai »

wyager wrote: post #196
yaakov34 wrote: post #90

There was a discussion here a few years ago ( https://news.ycombinator.com/item?id=2686580 ) about memory vulnerabilities in C. Some people tried to argue back then that various protections offered by modern OSs and runtimes, such as address space randomization, and the availability of tools like Valgrind for finding memory access bugs, mitigates this. I really recommend re-reading that discussion. My opinion, then a…

Speaking of proofs, how about we write security critical code in haskell? You need a very simple runtime, but beyond that it would work pretty much wherever. Most memory-related bugs are automatically eliminated, and security proofs are easier.

If you haven't seen it already, check out Cryptol from Gallois: http://corp.galois.com/cryptol/

It's a crypto DSL that I believe is implemented in Haskell (it compiles to Haskell, C, C++ and a few others).

Re: The Heartbleed Bug

#202

Post by nhaehnle »

ams6110 wrote: post #48
oskarth wrote: post #39

This thing has been in the wild for two years. What are the odds it hasn't been systematically abused? And what does this imply? To me it sounds kind of like finding out the fence in your backyard was cut open two years ago. Except in this case the backyard is two thirds of the internet.

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 attackers who did not know about the bug before it was publicly released, so some worry is still justified. I only wanted to point out that the "retroactively unfixable" is a misleading exaggeration.)

Re: The Heartbleed Bug

#203

Post by nwh »

gojomo wrote: post #70
tlrobinson wrote: post #42

Earlier quoted context omitted.

No, Bitcoin doesn't use SSL/TLS. It could have implications for Bitcoin web services that use HTTPS, of course.

Yes, Bitcoin the system/protocol doesn't inherently use TLS. But, with the "rpcssl=1" option, the reference Bitcoin client's RPC interface would be using SSL, and specifically OpenSSL. I'd guess a ton of online Bitcoin services reliant on hot wallets do this. So cue the thefts, or 'thefts', any minute now.

Nobody exposes their RPC port over ssl publicly. Nobody. You can't even do it if you use the normal settings in the client.

Re: The Heartbleed Bug

#204

Post by rst »

IgorPartola wrote: post #185

What are the chances that the NSA is having a field day with this in the 24-48 hours that it will take everyone to respond? Also, is it possible that CA's have been compromised to the point where root certs should not be trusted?

What are the odds that the NSA didn't already know about it? Even if you don't think they would have deliberately monkeywrenched OpenSSL (as they are widely believed to have done with RSA's BSAFE), they certainly have qualified people poring over widely used crypto libraries, looking for missing bounds checks and all manner of other faults --- quite likely with automated tooling.

As to CAs, there have been enough compromises already from other causes that serious crypto geeks like Moxie Marlinspike are trying to change the trust model to minimize the consequences --- see http://tack.io

Re: The Heartbleed Bug

#205

Post by est »

profquail wrote: post #200
pbsd wrote: post #191

Earlier quoted context omitted.

This sort of argument is becoming something of a fashion statement amongst some security people. It's not a strictly wrong argument: writing code in languages that make screwing up easy will invariably result in screwups. But it's a disingenuous one. It ignores the realities of systems. The reality is that there is currently no widely available memory-safe language that is usable for something like OpenSSL. .NET and…

Why not write the code in C# (for example) and extract it to $SYSTEM_PROGRAMMING_LANGUAGE? It wouldn't be much different than what Xamarin are doing now for creating iOS and Android apps with C#.

Because if you write that in C#, you have to bundle 54MB common runtime and GC withit.

Re: The Heartbleed Bug

#206

Post by sitkack »

squidsoup wrote: post #189
sitkack wrote: post #187

Earlier quoted context omitted.

Why port all the security vulns over to Rust? There are already a handful of SSL implementations, it isn't horribly hard to do. Maybe start with http://hackage.haskell.org/package/tls

I think over the last few months we've seen some pretty concrete evidence that implementing SSL securely is horribly hard to do.

I am saying that the benefits of porting a codebase that has had so many security vulnerabilities doesn't outweigh the cost of reimplementation.

Reimplementing a secure SSL implementation in a secure language is cheaper than porting the broken code.

Re: The Heartbleed Bug

#208

Post by digitalabyss »

rodgerd wrote: post #195
digitalabyss wrote: post #176

OK well I just updated about 40 servers. Has anyone started working with CAs to reissue SSL certificates signed with a new key? Are they willing to do the reissue for free? In particular I use RapidSSL for most things and Verisign for a few bigger clients who prefer it.

How do you know your CA isn't vulnerable?

I don’t; but I do not know how I could ever be sure. I’m a generalist sys admin and my knowledge of crypto is limited to the basics. That being said my understanding is that this vulnerability is in the code that creates the sessions not in the certificates themselves. The risk is that my key already was compromised when I was using the vulnerable version. For me this means two things:

1) There is no easy way for me to confirm or deny the CA is fixed short of attempting to exploit them.

2) Even if the CA is not fixed the vulnerability appears to in the routines used for session management not in the SSL certificate itself. While there is cc information and other stuff I would not like to be leaked, the CSR itself only contains my public key not my private key. As long as my servers are patched and I have a SSL cert using a new keypair that I know has not being compromised; I am not sure if the CA's version of openssl maters or not.

I am in no way trying to pretend I am an expert. I am sure there are problems with my analysis but it still feels like its time to be pragmatic and get a fix in place before asking all the what-ifs. Not that those questions should not be asked but it’s a mater of prioritizing.

Re: The Heartbleed Bug

#209

Post by yaakov34 »

azth wrote: post #183
yaakov34 wrote: post #154

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…

>(2) lots of complicated ways to screw up, such as not properly allocating/deleting things deep in some templated structure Wow, that sounds scary. Do you have any references or further reading about this?

I don't have a reference, but I've seen this myself. Problems can happen whenever pointers combined with the STL or other modern C++ stuff. In the thread from several years ago, I gave as an example pushing a pointer to a local variable into a vector which is then returned somewhere outside of scope. Compilers don't warn about this, or at least didn't then, although Valgrind catches it. And of course this can be a more complicated case, like a vector of maps from strings to structures containing pointers which is passed by reference somewhere - which will make it harder to catch. And Valgrind won't help if it doesn't see it happening in the execution path that you ran.

Now, combining pointers and STL is not a good idea. In fact, using raw pointers in C++ is not a good idea, at least IMO (but you've seen I am a bit concerned about memory safety). However, this is perfectly supported by compilers, and not even seriously discouraged (some guides tell you to be careful out there). I've seen difficult bugs produced by this, in my case, in a complicated singleton object.

Re: The Heartbleed Bug

#210

Post by pbsd »

profquail wrote: post #200
pbsd wrote: post #191

Earlier quoted context omitted.

This sort of argument is becoming something of a fashion statement amongst some security people. It's not a strictly wrong argument: writing code in languages that make screwing up easy will invariably result in screwups. But it's a disingenuous one. It ignores the realities of systems. The reality is that there is currently no widely available memory-safe language that is usable for something like OpenSSL. .NET and…

Why not write the code in C# (for example) and extract it to $SYSTEM_PROGRAMMING_LANGUAGE? It wouldn't be much different than what Xamarin are doing now for creating iOS and Android apps with C#.

Using C as an output language, backed by guarantees at the higher level, could certainly work. I believe ATS [1] works this way, and can even avoid garbage collection altogether if desired. I understand it is not an easy language, though.

Nimrod [2] also generates C, but as I understand it garbage collection is unavoidable.

[1] http://www.ats-lang.org/

[2] http://nimrod-lang.org/

Post reply on HN