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

101–110 of 547 posts

Re: The Heartbleed Bug

#101

Post by M4v3R »

josh-wrale wrote: post #91
M4v3R wrote: post #86

Earlier quoted context omitted.

Ok, anyone could assist me on how to update openssl without breaking anything? I've fetched newest sources from openssl.org and compiled them, but "make install" doesn't actually install it, it only got compiled, but issuing "openssl version" still gives me the old version. What I want to do is to patch it so our webserver uses new version.

I would tread lightly here if you aren't comfortable with compiling. Rather than break your website, it might be better to take it down until your distro's packages are available. You should probably spend your time investigating a good method of reissuing keys for when you get to a stable OpenSSL version. Some apps have OpenSSL statically compiled into the binaries. Beware that what you think is fixed may not be.

Well, I'm not really in position of taking the whole service down at this moment, I would really like to have a way to patch it instead.

Re: The Heartbleed Bug

#102

Post by azth »

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…

That's why I have high hopes for Rust. We really need to move away from C for critical infrastructure. Perhaps C++ as well, though the latter does have more ways to mitigate certain memory issues.

Incidentally, someone on the mailing list brought up the issue of having a compiler flag to disable bounds checking. However, the Rust authors were strictly against it.

Re: The Heartbleed Bug

#103

Post by tlrobinson »

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.

True, though I would hope most services don't have public facing bitcoind instances to begin with...

Re: The Heartbleed Bug

#104

Post by throwaway2048 »

mark-r wrote: post #50
mark-r wrote: post #37

Any chance this bug originated with the NSA? It seems like it would fall under their goal of subverting the infrastructure that keeps secrets on the internet. Of course this is exactly why such a goal is a bad idea - an unprotected internet causes widespread damage.

I knew I was going to be attacked for saying this, but isn't it a real possibility? We already know that they tried to weaken RSA.

they did not try to "weaken RSA", as in the RSA algorithm. They paid off and/or infiltrated RSA the corporation. You were not attacked, your posts simply contained wrong information and useless speculation.

Screaming about the NSA every time a security bug comes up is not interesting, productive, insightful, or useful, please stop.

Re: The Heartbleed Bug

#105

Post by yaakov34 »

lawl wrote: post #98
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…

If that would work Virtual Machines and runtimes wouldn't have vulnerabilities. So uhm. Yeah, that doesn't work either. Edit: Btw since HN has this obessions with Tarsnap, it's written in C btw. So you should stop obessing about it and downvote me some more.

This argument came up in the thread from a few years ago. It is quite wrong-headed. I would like to give a clear answer to it:

Virtual machines and runtimes may be vulnerable to malicious CODE. That's bad. Programs written in unmanaged languages are vulnerable to malicious DATA. That's horrible and unmitigatable.

Vulns to malicious code are bad, but they may be mitigated by not running untrusted code (hard, but doable in contexts of high security). They are also mitigated by the fact that the runtime or VM is a small piece of code which may even be amenable to formal verification.

Vulns to malicious data, or malicious connection patterns, are impossible to avoid. You can't accept only trusted data in anything user-facing. Also, these vulnerabilities are spread through billions of lines of application and OS code, as opposed to core runtime/VM.

Re: The Heartbleed Bug

#106

Post by ori_b »

lawl wrote: post #98
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…

If that would work Virtual Machines and runtimes wouldn't have vulnerabilities. So uhm. Yeah, that doesn't work either. Edit: Btw since HN has this obessions with Tarsnap, it's written in C btw. So you should stop obessing about it and downvote me some more.

In keeping with the tradition of bad car analogies, that's like saying "Driving cars with automatic traction control won't make accidents go away, so automatic traction control is pointless".

Languages with bounds checks on array accesses don't solve everything, but that doesn't mean that they don't work. They do remove entire classes of silent failures that can potentially slip through the cracks in C-like languages. VMs aren't needed for this -- most of the strongly typed functional languages, D, Go, Rust, and others all compile down to native machine code.

Careful API design, discipline, and good coding in C can also mitigate this sort of problem manually, although (like most things in C), it's extra work, and needs careful thought to ensure correctness.

Re: The Heartbleed Bug

#107

Post by whyleyc »

gsnedders wrote: post #71
whyleyc wrote: post #57

This doesn't sound like "responsible disclosure" to me - how can Codenomicon dump this news when all the major Linux vendors don't have patches ready to go ?

Because it was already disclosed the instant the OpenSSL release went out and the fix was public.

Well someone was able to give Cloudflare a heads up last week [1].

It would have been nice if the package maintainers could have had time to build ready-to-roll solutions with Heartbeat compiled out prior to the official OpenSSL fix.

[1] http://blog.cloudflare.com/staying-ahead-of-openssl-vulnerab...

Re: The Heartbleed Bug

#108

Post by snewman »

lawl wrote: post #98
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…

If that would work Virtual Machines and runtimes wouldn't have vulnerabilities. So uhm. Yeah, that doesn't work either. Edit: Btw since HN has this obessions with Tarsnap, it's written in C btw. So you should stop obessing about it and downvote me some more.

VMs generally do not have this type of vulnerability (buffer overrun).

Also, most vulnerabilities in (e.g.) the JVM can only be exploited by running malicious code inside the VM. Here, the attacker is supplying data used by OpenSSL, but is not able to supply arbitrary code.

Re: The Heartbleed Bug

#109

Post by josh-wrale »

M4v3R wrote: post #101
josh-wrale wrote: post #91

Earlier quoted context omitted.

I would tread lightly here if you aren't comfortable with compiling. Rather than break your website, it might be better to take it down until your distro's packages are available. You should probably spend your time investigating a good method of reissuing keys for when you get to a stable OpenSSL version. Some apps have OpenSSL statically compiled into the binaries. Beware that what you think is fixed may not be.

Well, I'm not really in position of taking the whole service down at this moment, I would really like to have a way to patch it instead.

Depending on the distro on which you're based, you may find that making a new package from a source package (e.g. srpm) would be the safest route even if you're in a hurry.

If you're on Ubuntu, it would appear at least the updated base (OpenSSL itself) packages are now in the repos.

http://people.canonical.com/~ubuntu-security/cve/2014/CVE-20...

Re: The Heartbleed Bug

#110

Post by eastdakota »

rincebrain wrote: post #94
chomp wrote: post #33

How did Cloudflare get access to this bug a week before it was made public, yet no distro has a package ready? How's that for responsible disclosure?

I believe the reason they got access was one of their customers found it and reported it to them, and they reported it to OpenSSL, and then it somehow leaked (either with the OSSL release, or someone else) and then they posted their now-public writeups of it.

That's not correct. One of the individuals who discovered the bug contacted us as a large provider of SSL termination services. We were asked not to further disclose the details until it was officially patched and announced by OpenSSL. The official announcement occurred today after which we put up a post to let our customers know that they were protected.
Post reply on HN