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

281–290 of 547 posts

Re: The Heartbleed Bug

#281

Post by e12e »

Dylan16807 wrote: post #244
jcalvinowens wrote: post #239

Earlier quoted context omitted.

> There are languages that make it very very hard to write bad code. Haskell [...] Sure, but how much slower is Haskell than an equivalent implementation in C? Some quick searching suggests numbers like 1000% slower... and no amount of security is worth a 1000% performance hit, let alone a vague "security mistakes are less likely this way" sort of security. Being secure is useless if your code is so slow that you hav…

>no amount of security is worth a 1000% performance hit Yes it is. Most of the applications I use take roughly 0% of my processor's capacity. I can spare a multiple like that outside of a few hot loops. Saying 10x slowdown isn't worth it is like saying no one would ever compute on a phone. Also random BS benchmark http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... says haskell is at least half as fast as…

"Performance is a quality of a working system." And doubly so for a cryptographic system.

What good is a cryptographic library that's not secure? Worse than no good. If you're not encrypting your data, you (should) be aware of that, and act accordingly. On the other hand, if you think you're encrypting your data...

Re: The Heartbleed Bug

#282

Post by spatten »

house9-2 wrote: post #143
dmix wrote: post #72

Earlier quoted context omitted.

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

I'm totally confused by this. I'm running ubuntu LTS 12.04 and did

    sudo aptitude update
    sudo aptitude upgrade openssl
and then ran

    openssl version -a
and got the same results as you. How can it be built on January 8th if the patch was just made today?

[EDIT] running

    sudo aptitude upgrade
upgraded properly and now I'm getting a version that was compiled earlier today. I'm guessing I needed to update another package as well. Probably `libssl`?

Re: The Heartbleed Bug

#283

Post by e12e »

YZF wrote: post #218
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…

I'd disagree with your disagreement ;-) C++ has constructs that let you build safer and more secure systems while maintaining good performance. You can write high performance systems without ever touching a raw pointer or doing manual memory management which is something that you can't really do in any other language. Yes, you need to trust the underlying library code which is something you have to do for pretty much…

Does anyone have experience with (auditing) systems built using pascal/delphi? I realize that Ada might be a better choice if headed in that direction -- but it always felt to me like pascal actually had a pretty sane trade-off between high and low level, and that C generally gave a lot of the bad parts of assembly while still managing to obfuscate the code without really giving that much in terms of higher level structure.

Re: The Heartbleed Bug

#284

Post by imsofuture »

clev wrote: post #273
imsofuture wrote: post #171

Earlier quoted context omitted.

Likewise, same question for Rackspace's Cloud LBs.

Rackspace guy here. We have been digging in and it appears that we did have the impacted version of openssl installed but the heartbeat extension was disabled. Regardless, we have updated everything on the Cloud Load Balancer side to 1.0.1g. I will update here if we find anything different.

Rockin, thanks for the update!

Re: The Heartbleed Bug

#285

Post by kseifried »

RHEL updates are available: https://rhn.redhat.com/errata/RHSA-2014-0376.html

CentOS updates are available: http://lists.centos.org/pipermail/centos-announce/2014-April...

Fedora updates are available, hitting the mirrors, but you can get it earlier, instructions here: https://lists.fedoraproject.org/pipermail/announce/2014-Apri... https://lists.fedoraproject.org/pipermail/announce/2014-Apri...

Re: The Heartbleed Bug

#286

Post by mietek »

pbsd wrote: post #227
rtpg wrote: post #211

Earlier quoted context omitted.

>Additionally, although the parsing portions of OpenSSL need not deal with the hardware directly, the crypto portions do. So your memory-safe language needs some first-class escape hatch to unsafe code. A few of them do have this, others not so much. For the other points there is some debate, but don't most serious languages have a C FFI?

OpenSSL and similar libraries spend most of their time processing short packets. For example, encrypting a few hundred bytes using AES these days should take only a few hundred CPU cycles. This means that the overhead of calling the crypto code should be minimal, preferably 0. This is in part what I meant by "first-class". Perhaps I should have written "zero-overhead" instead. I googled around just now for some bench…

This project attempts to measure the overhead of calling out from $LANGUAGE and into C, which is the reverse of what's necessary to solve the problem stated here — to write a low-level library in a high-level language.

There are other means of achieving a secure implementation, such as programming in a very high-level language, such as Cryptol, and compiling to a low-level language:

http://corp.galois.com/cryptol/

Re: The Heartbleed Bug

#287

Post by syncsynchalt »

snewman wrote: post #166
earless1 wrote: post #46

Earlier quoted context omitted.

That is my concern as well. We are still running CentOS 6.4 which does not have the affected version of OpenSSL, but we terminate SSL at the ELB so if they are affected then are keys are not safe. Edit: I've posted on the support forum, hopefully they get back to us https://forums.aws.amazon.com/thread.jspa?threadID=149690

I opened a support ticket, and Amazon just responded to say that yes, ELBs are vulnerable. I've posted their reply into that thread.

Any ELB deploys I've done in the last hour seem to be fixed.

Re: The Heartbleed Bug

#288

Post by vesinisa »

ahomescu1 wrote: post #212
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…

> This vulnerability is the result of yet another missing bound check. It wasn't discovered by Valgrind or some such tool, since it is not normally triggered - it needs to be triggered maliciously or by a testing protocol which is smart enough to look for it (a very difficult thing to do, as I explained on the original thread). You could also look at this bug as an input sanitization failure. The author didn't consid…

The defined behaviour would be to discard the packet. In a secure language, the buffer would have had a "length" property, and the code would have crashed when a read beyond the buffer's end was attempted. But in C, buffers are just pointers, so there is fundamentally nothing wrong with reading beyond the end of the buffer. So instead of a crash, we get silent memory exposure.

Re: The Heartbleed Bug

#289

Post by perturbation »

Node.js sort-of dodged a bullet here. It includes a version of openssl that it links against when building the crypto module (and, I would think, the tls module). Node.js v0.10.26 uses OpenSSL 1.0.1e 11 Feb 2013.

However (in openssl.gyp): https://github.com/joyent/node/blob/master/deps/openssl/open...

It disables the heartbeat with the compile time option due to a workaround for Microsoft's IIS, of all things.

So the affected window for node would have been Sep 11, 2012 to Mar 27, 2013 (based on the commit history).

Post reply on HN