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

121–130 of 547 posts

Re: The Heartbleed Bug

#121

Post by sanderjd »

azth wrote: post #102
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.

I'm excited about Rust for this reason as well, but in practice I find myself thinking a lot about data moving into and out of various C libraries. The great but inevitably imperfect theory is that those call sites are called out explicitly and should be as limited as possible. It works well but isn't a silver bullet. I'm hopeful that as the language ecosystem matures there will be increasingly mature C library wrappers and (even better!) native, memory-safe, Rust replacements for things.

Re: The Heartbleed Bug

#122

Post by jamesaguilar »

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…

> Your might get less buffer overruns okay, but is it more secure in the end without any doubt?

If you hold everything else constant, yes, less buffer overruns == more secure.

Re: The Heartbleed Bug

#123

Post by pyvpx »

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 don't know -- why don't you try reasoning it out since you're the one lobbing the accusation. Upon a very simple review of the code change/patch, one can see this is a relatively new feature, agreed upon and passed by the publicly available IETF, implemented naively.

"Never attribute to malice that which can be adequately explained by incompetence" -- slightly-butchered quote, from someone smarter than me.

Re: The Heartbleed Bug

#124

Post by smtddr »

ams6110 wrote: post #30
cheald wrote: post #2

What a great writeup. Comprehensive without being overly verbose, answers to "what does this mean?" and "does this affect me?", and clear calls to action. While I'm not happy at having to spend my Monday patching a kajillion machines, I welcome more vulnerability writeups in this vein.

Writeup was too long. We need to know the short and sweet of what to fix.

What? ...As soon as the page loads it's right there without having to scroll the page:

http://i.imgur.com/ZwTclan.png

(What I want now is an exploit.c, PoC.py, pwnSSL.rb, etc... but I guess it would be irresponsible to provide that to the script-kiddies of the interwebz right now)

Re: The Heartbleed Bug

#125

Post by brown9-2 »

iso8859-1 wrote: post #9

Here's the patch/commit, I don't know why it's not linked form the OpenSSL changelog or heartbleed.com. A suspicious lack of transparency. http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=...

if (1 + 2 + 16 > s->s3->rrec.length)

I don't know C well - why write 19 like this?

Re: The Heartbleed Bug

#126

Post by Karunamon »

javajosh wrote: post #114
mark-r wrote: post #50

Earlier quoted context omitted.

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.

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, especially since some very sneaky and pernicious bugs can be introduced in the guise of simple mistakes. It would be foolish to assume this isn't part of the standard playbook, and just as foolish to discount the possibility of maliciously introduced bugs just because the evidence doesn't immediately point to malicious intent - that is the nature of the attacker.

The alternative is remaining ignorant and vulnerable to the single most well funded and experienced adversary a crypto user will ever likely face.

Re: The Heartbleed Bug

#127

Post by chokma »

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.

With "openssl version -a" you can see the built time.

  root@x ~ # openssl version -a
  OpenSSL 1.0.1 14 Mar 2012
  built on: Mon Apr  7 20:33:29 UTC 2014

Re: The Heartbleed Bug

#128

Post by syzzer »

NelsonMinar wrote: post #32
iso8859-1 wrote: post #9

Here's the patch/commit, I don't know why it's not linked form the OpenSSL changelog or heartbleed.com. A suspicious lack of transparency. http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=...

I'm very curious to see the change that introduced the bug in the first place. According to the announcement it was introduced in 1.0.1. That's the version that added Heartbeat support, so maybe it was a bug from the beginning.

Yes, this has been introduced in the original heartbeat extension commit (01-01-2012):

http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=bd69...

Re: The Heartbleed Bug

#129

Post by mark-r »

pyvpx wrote: post #123
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 don't know -- why don't you try reasoning it out since you're the one lobbing the accusation. Upon a very simple review of the code change/patch, one can see this is a relatively new feature, agreed upon and passed by the publicly available IETF, implemented naively. "Never attribute to malice that which can be adequately explained by incompetence" -- slightly-butchered quote, from someone smarter than me.

It's not an accusation, it's a speculation. I don't have the ability to judge it for myself, i.e. "a simple review of the code change/patch". That's why I put it out there. I don't mind being refuted, but I wish it would be refuted rather than just downvoted blindly.

P.S. I think your quote doesn't capture the situation properly when someone is known to have malicious intent.

Post reply on HN