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

131–140 of 547 posts

Re: The Heartbleed Bug

#131

Post by yaakov34 »

lawl wrote: post #115
yaakov34 wrote: post #105

Earlier quoted context omitted.

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 doabl…

What? Sorry, that doesn't make the least amount of sense. If you have a VM your code is DATA! You can have say format string bugs in managed languages too, see for example: http://blog.stalkr.net/2013/06/golang-heap-corruption-during... I'm sorry, but you're agrument here is plain bullshit. Using your logic the whole kernel/browsers etc should be written in a managed language. A browser is basically a VM for webpages…

I am afraid you are the one who is not showing signs of having thought about this deeply. What is the ratio of the number of application programs, libraries, and services to the number of VMs and runtimes? Thousands, tens of thousands, millions? Depends on how you count, but it's huge. Reducing the attack surface like this is a big win.

And it is indeed a bad idea to install a browser on a critical server, and to load untrusted sites in it. You can mitigate the problem by not doing that. You can't stop the server from dealing with user data, though, since for many servers, that's what they are for. (If you are not going to deal with untrusted data, it is preferable to disable untrusted connections at as low a level as you can manage).

Re: The Heartbleed Bug

#132

Post by mrottenkolber »

yaakov34 wrote: post #105
lawl wrote: post #98

Earlier quoted context omitted.

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 doabl…

  Virtual machines and runtimes may be vulnerable to malicious CODE. That's bad. 
  Programs written in unmanaged languages are vulnerable to malicious DATA.
Not exatly true. You can still write code vulnerable to input (data) in a "secure" language by accident. C is just especially vulnerable to buffer stuff.

Re: The Heartbleed Bug

#133

Post by chokma »

sjaak_trekhaak wrote: post #88
mfwoods wrote: post #73

Earlier quoted context omitted.

I just installed update openssl_1.0.1e-2+deb7u5 and libssl1.0.0_1.0.1e-2+deb7u5 on debian wheezy, so it seems the fix is now available.

Just received an upgrade on Ubuntu 12.04 LTS as well, apt-get clean issued before updating. EDIT: If you are using DigitalOcean, the update is not yet on their mirrors. Issue 'sudo sed -i "s/mirrors\.digitalocean/archive.ubuntu/g" /etc/apt/sources.list;sudo apt-get clean;sudo apt-get update;sudo apt-get upgrade' to get the patch. Check the comment by 0x0 above ( https://news.ycombinator.com/item?id=7549842 ) to find…

Same for hetzner.de: the default sources.list points to their [for the moment] outdated update-server.

Re: The Heartbleed Bug

#134

Post by orblivion »

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.

Not again. GAH. I just did this after GnutlsGate.

Re: The Heartbleed Bug

#135

Post by imsofuture »

stormbrew wrote: post #120
dmix wrote: post #72

Earlier quoted context omitted.

This is the standard command: $ openssl version > OpenSSL 1.0.1f 6 Jan 2014

As far as I can tell, on ubuntu this reports "OpenSSL 1.0.1 14 Mar 2012" for all ubuntu versions, including the fixed one.

try: dpkg -s openssl

Re: The Heartbleed Bug

#136

Post by javajosh »

Karunamon wrote: post #126
javajosh wrote: post #114

Earlier quoted context omitted.

It is evil to make totally unsupported accusations, even against the NSA. I've downvoted you, twice.

Asking "did they do this?" is not an accusation, seriously. And even then, the NSA has had their fingers in enough places and lied about it enough times (infiltrating FOSS projects was explicitly one of their goals, IIRC) that the sane default position would be to assume shenanigans on their part unless proven otherwise. The vetting process does absolutely nothing to prevent something like this from happening, especi…

>Asking "did they do this?" is not an accusation, seriously.

Nonsense. Are you a child-molester? I'm just asking, not accusing you of anything.

Re: The Heartbleed Bug

#137

Post by mstrem »

From the CloudFlare blog: "This bug fix is a successful example of what is called responsible disclosure".

I just discovered this now and

    yum info openssl
Yields 1.0.1e as available package which is vulnerable. I guess not all "stakeholders" have been warned properly - or am I jumping to conclusions?

Re: The Heartbleed Bug

#138

Post by ama729 »

ineedtosleep wrote: post #4

A couple more data points: I'm running Fedora 19 and Arch on my main dev machines/VMs and as of this posting are considered up-to-date. Both are vulnerable: [Fedora19] $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 [Arch] $ openssl version OpenSSL 1.0.1f 6 Jan 2014

Ubuntu (and I suppose Debian too), just released a fix in 13.10.

Re: The Heartbleed Bug

#139

Post by amalcon »

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…

Nothing in the standard prevents a C compiler + tightly coupled malloc implementation from implementing bounds checks. Out-of-bounds operations result in undefined behavior, and crashing the program is a valid response to undefined behavior. If your malloc implementation cooperates, you can even bounds-check pointer arithmetic without violating calling conventions.

It's quite a shame that there isn't a compiler that does this, and it's a project I've considered spending some time on if I can find a big enough block of that to get a solid start.

Re: The Heartbleed Bug

#140

Post by Karunamon »

javajosh wrote: post #136
Karunamon wrote: post #126

Earlier quoted context omitted.

Asking "did they do this?" is not an accusation, seriously. And even then, the NSA has had their fingers in enough places and lied about it enough times (infiltrating FOSS projects was explicitly one of their goals, IIRC) that the sane default position would be to assume shenanigans on their part unless proven otherwise. The vetting process does absolutely nothing to prevent something like this from happening, especi…

>Asking "did they do this?" is not an accusation, seriously. Nonsense. Are you a child-molester? I'm just asking, not accusing you of anything.

The difference being I don't have a history of doing such things and then repeatedly lying about it....
Post reply on HN