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

141–150 of 547 posts

Re: The Heartbleed Bug

#141

Post by scintill76 »

brown9-2 wrote: post #125
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?

Probably to make it more clear what you're referring to, and double-check yourself. There are probably components that are 1 byte, 2 bytes, and 16 bytes long. Writing it out makes it clear and eliminates a chance for human error in the sum, more than a magic 19 does. (I guess 16 is pretty magical too, though. At least it's a "round" number, and in context may be a well-known field size of something in the protocol.)

Re: The Heartbleed Bug

#142

Post by thisrod »

ori_b wrote: post #106
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.

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…

Do you know of any controlled experiments to test the safety claims for automatic traction control? People used to say similar things about ABS. Then the experiments were done, it turned out to be pointless or possibly dangerous, and people started talking about traction control instead.

Automatic bounds checking could well fail the same way that ABS did: programmers won't bother defining a packet data type, because the compiler will catch any mistakes they make fiddling with arrays. So, like drivers with ABS, programmers with ABC would go faster, but they wouldn't be any safer.

Re: The Heartbleed Bug

#143

Post by house9-2 »

dmix wrote: post #72
earless1 wrote: post #56

Earlier quoted context omitted.

On my CentOS boxes I ran 'yum list | grep openssl'

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

@stormbrew is correct about ubuntu, use -a or -v -b

    openssl version -v -b

    OpenSSL 1.0.1 14 Mar 2012
    built on: Wed Jan  8 20:45:51 UTC 2014

Re: The Heartbleed Bug

#144

Post by eikenberry »

0x0 wrote: post #81
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.

You need to manually restart all processes linking libssl, too. Something like "lsof -n | grep ssl | grep DEL" can identify processes using the DELeted old version of libssl after apt-get upgrading.

Debian comes with a handy tool for this called 'checkrestart' in the debian-goodies package.

    sudo apt-get install debian-goodies
    sudo checkrestart

Re: The Heartbleed Bug

#145

Post by jdiez17 »

brown9-2 wrote: post #125
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?

Those numbers probably have some significance. `1` seems to be "heartbeat type" and `2` seems to be "heartbeat length".

Re: The Heartbleed Bug

#146

Post by hamburglar »

smtddr wrote: post #124
ams6110 wrote: post #30

Earlier quoted context omitted.

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)

The part that's caused me to read this page several times over without a clear answer is that they mention that private keys may be leaked, but their calls to action do not recommend generating new private keys. How does that make any sense?

Re: The Heartbleed Bug

#148

Post by georgemcbay »

scintill76 wrote: post #141
brown9-2 wrote: post #125

Earlier quoted context omitted.

if (1 + 2 + 16 > s->s3->rrec.length) I don't know C well - why write 19 like this?

Probably to make it more clear what you're referring to, and double-check yourself. There are probably components that are 1 byte, 2 bytes, and 16 bytes long. Writing it out makes it clear and eliminates a chance for human error in the sum, more than a magic 19 does. (I guess 16 is pretty magical too, though. At least it's a "round" number, and in context may be a well-known field size of something in the protocol.)

Yeah, this. It is fairly common to see things like this in C-like languages when it comes to times, like when including the milliseconds in a day you might see:

int timeout = 1000 * 60 * 60 * 24;

(milliseconds in a second * 60 for minute, * 60 for hour, * 24 for hours in a day).

Much more obvious than just putting in 86400000, and the compiler will optimize away the math and putting the math in there explicitly is arguably better than a comment that could easily become unanchored from the real value (if someone changes the value and forgets to update the comment).

When it comes to byte-sizes of things, though, most code will use sizeof() to both make it more clear where these numbers are coming from and to make them automatically adjust if the structure sizes change (granted this is unlikely to happen on a mature protocol).

At the very least having them be preprocessor defines would certainly make things a lot more clear here, so even for C I'd consider this a bit of a "code smell" (though the people who work on this code regularly are probably versed enough in the ssl3 record structure enough that they immediately grok this when they see it).

Re: The Heartbleed Bug

#149

Post by 0x0 »

eikenberry wrote: post #144
0x0 wrote: post #81

Earlier quoted context omitted.

You need to manually restart all processes linking libssl, too. Something like "lsof -n | grep ssl | grep DEL" can identify processes using the DELeted old version of libssl after apt-get upgrading.

Debian comes with a handy tool for this called 'checkrestart' in the debian-goodies package. sudo apt-get install debian-goodies sudo checkrestart

Thanks for the hint, I hadn't heard of this one. Should be built-in to apt, I think! :)

Re: The Heartbleed Bug

#150

Post by malandrew »

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…

Is anyone working on an OpenSSL port in rust, which lacks the memory vulnerabilities of C?
Post reply on HN