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

91–100 of 547 posts

Re: The Heartbleed Bug

#91

Post by josh-wrale »

M4v3R wrote: post #86
lawl wrote: post #79

Earlier quoted context omitted.

Agree. This needs a big fat the world is coming to an end stlye of warning. I've just shut down the webservers running SSL that I can control. If you are vuln and don't want to build openssl from source and can afford the outage. I'd reccomend to do the same. OTHERWISE BUILD FROM SOURCE IMMEDIATELY, PATCH, AND GET NEW KEYS! Let's hope CA's don't get swamped by all the CSR's. Or rather let's hope they do so we see peo…

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.

Re: The Heartbleed Bug

#92

Post by mfwoods »

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.

Thanks for reminding, almost forgot about that.

Re: The Heartbleed Bug

#94

Post by rincebrain »

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.

Re: The Heartbleed Bug

#95

Post by earless1 »

lawl wrote: post #79
phillmv wrote: post #51

Given the severity of this bug, the UX of the site is failing anyone who isn't a fulltime sysadmin. Suggestion: big, bold TLDR ("The sky is falling. Check your OpenSSL version right now") with a link on what to do sorted by OS vendor. Step 1: Here's a command to spit out your OpenSSL version. If it is the following string, go to step 2. Step 2: Here's how to update your OpenSSL. Here are links to guides on reissuing…

Agree. This needs a big fat the world is coming to an end stlye of warning. I've just shut down the webservers running SSL that I can control. If you are vuln and don't want to build openssl from source and can afford the outage. I'd reccomend to do the same. OTHERWISE BUILD FROM SOURCE IMMEDIATELY, PATCH, AND GET NEW KEYS! Let's hope CA's don't get swamped by all the CSR's. Or rather let's hope they do so we see peo…

Not to sound like a commercial for Cloudflare or anything. But putting your infrastructure behind their services can protect users while they perform their patching. According to their latest blog post http://blog.cloudflare.com/staying-ahead-of-openssl-vulnerab...

Re: The Heartbleed Bug

#96

Post by makomk »

mikeash wrote: post #25

I don't quite understand how this bug works. I would appreciate any input from someone knowledgeable. It sounds like the heartbeat code is sending some data in the handshake. That data should be harmless (padding? zeroes?) but the bug results in reading off the end of an array and from whatever other data happens to be there. Someone sniffing the connection can then see those bytes fly by. If they happened to contain…

One obvious - if slightly paranoid - answer is that this was a deliberate backdoor. There appears to be a length field specific to the heartbeat packet that's used to determine how much data from the original packet is included in the response, isn't checked against the actual packet length, and allows lengths up to 64k which is unnecessarily generous for the intended purpose but very useful for this attack.

Re: The Heartbleed Bug

#97

Post by [deleted] »

MartinMond wrote: post #20

As of now (21:04 UTC) this isn't fixed in Debian https://security-tracker.debian.org/tracker/CVE-2014-0160 nor Ubuntu http://people.canonical.com/~ubuntu-security/cve/2014/CVE-20... Got a long night ahead :/

[deleted]

Re: The Heartbleed Bug

#98

Post by lawl »

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.

Re: The Heartbleed Bug

#99

Post by josh-wrale »

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…

I can confirm this for vanilla Ubuntu 12.04 LTS. I've been checking for the past hour. The updates for the following just appeared:

Setting up libssl-doc (1.0.1-4ubuntu5.12) ... Setting up libssl-dev (1.0.1-4ubuntu5.12) ... Setting up openssl (1.0.1-4ubuntu5.12) ...

Re: The Heartbleed Bug

#100

Post by drv »

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…

From a quick reading of the TLS heartbeat RFC and the patched code, here's my understanding of the cause of the bug.

TLS heartbeat consists of a request packet including a payload; the other side reads and sends a response containing the same payload (plus some other padding).

In the code that handles TLS heartbeat requests, the payload size is read from the packet controlled by the attacker:

  n2s(p, payload);
  pl = p;
Here, p is a pointer to the request packet, and payload is the expected length of the payload (read as a 16-bit short integer: this is the origin of the 64K limit per request).

pl is the pointer to the actual payload in the request packet.

Then the response packet is constructed:

  /* Enter response type, length and copy payload */
  *bp++ = TLS1_HB_RESPONSE;
  s2n(payload, bp);
  memcpy(bp, pl, payload);
The payload length is stored into the destination packet, and then the payload is copied from the source packet pl to the destination packet bp.

The bug is that the payload length is never actually checked against the size of the request packet. Therefore, the memcpy() can read arbitrary data beyond the storage location of the request by sending an arbitrary payload length (up to 64K) and an undersized payload.

I find it hard to believe that the OpenSSL code does not have any better abstraction for handling streams of bytes; if the packets were represented as a (pointer, length) pair with simple wrapper functions to copy from one stream to another, this bug could have been avoided. C makes this sort of bug easy to write, but careful API design would make it much harder to do by accident.

Post reply on HN