#2215 closed defect (somebody else's problem)

mitigate heartbleed vulnerability

Reported by: daira Owned by: daira
Priority: major Milestone: 1.12.0
Component: code Version: 1.10.0
Keywords: security integrity confidentiality capleak pyopenssl cffi packaging manual-test-needed Cc:
Launchpad Bug:

Description (last modified by daira)

Check the OpenSSL version number and refuse to run if vulnerable.

Also see #2222 (make a FAQ describing the impact of heartbleed on Tahoe-LAFS).

Change History (27)

comment:2 Changed at 2014-04-10T17:41:29Z by daira

  • Keywords review-needed added

Review needed for https://github.com/tahoe-lafs/tahoe-lafs/commits/2215-refuse-vulnerable-openssl.

(This should not be committed until we have built some non-vulnerable pyOpenSSL eggs.)

Last edited at 2014-04-10T18:01:10Z by daira (previous) (diff)

comment:4 Changed at 2014-04-11T16:22:01Z by daira

The current branch implements a different policy:

  • versions 0.9.8y+ in the 0.9.8 series are allowed;
  • versions 1.0.0l+ in the 1.0.0 series are allowed;
  • versions 1.0.1d through 1.0.1f are allowed iff compiled with -DOPENSSL_NO_HEARTBEATS or with a build date on or after 6 April 2014;
  • versions 1.0.1g+ are allowed.

Also,

  • the error handling has changed;
  • there are more tests covering the cases above.

Re-review needed.

comment:5 Changed at 2014-04-11T16:22:54Z by daira

Please refer to http://www.openssl.org/news/vulnerabilities.html for information about when vulnerabilities were fixed.

comment:6 Changed at 2014-04-12T10:50:31Z by daira

  • Keywords integrity confidentiality capleak cffi packaging added

It was suggested on #cryptography-dev that (rather than looking at build date as the patch currently does), we should call the tls1_process_heartbeat function to directly check whether it is vulnerable. (This is possible without invoking undefined behaviour.)

For pyOpenSSL >= 0.14, this can be done relatively easily by importing OpenSSL._util._lib, which gives access to arbitrary OpenSSL functions via cffi. For pyOpenSSL 0.13, however, it's basically impossible because there is no way to add to the set of OpenSSL functions exposed by the extension module. I don't know where that leaves us, given the cffi-related build problems described in #2193 and #2117.

Version 0, edited at 2014-04-12T10:50:31Z by daira (next)

comment:7 Changed at 2014-04-12T10:51:55Z by daira

  • Owner set to zooko

comment:8 Changed at 2014-04-15T01:50:40Z by daira

  • Description modified (diff)

comment:9 follow-up: Changed at 2014-04-15T16:30:32Z by zooko

There is a proposal in this email for a way to convey the information that a particular package has the heartbleed fix: pipermail/tahoe-dev/2014-April/008988.html. However, it requires cooperation from the pyOpenSSL devs.

comment:10 in reply to: ↑ 9 Changed at 2014-04-15T17:41:54Z by zooko

Replying to zooko:

There is a proposal in this email for a way to convey the information that a particular package has the heartbleed fix: pipermail/tahoe-dev/2014-April/008988.html. However, it requires cooperation from the pyOpenSSL devs.

Here is the core of the proposal:

Here's an idea that could make a cleaner way for both Tahoe-LAFS and also other code that uses pyOpenSSL to deal with this:

The pyOpenSSL maintainers could make new releases of pyOpenSSL, named "0.14.1" and (for people like us who can't upgrade to the cffi-based build system yet) "0.13.1". The ".1"'s in these version numbers are being used as a signal, visible within the Python packaging metadata, that this particular package was built by someone who is aware of heartbleed and they intended to remove the heartbleed vuln from this package. Then Tahoe-LAFS (and Foolscap, and Twisted, etc.) can depend on "pyOpenSSL == 0.13.1, >= 0.14.1", to indicate their desire to listen to this signal.

Then the pyOpenSSL setup.py can help the builder of the package send the correct signal, by checking the version number of OpenSSL and refusing to build if it is one of the version numbers that had (in the upstream OpenSSL release) the heartbleed vuln.

Now, Debian and Ubuntu ship OpenSSL libraries which have a patch to fix the vuln but which still report the original upstream OpenSSL version numbers. No problem! When they build pyOpenSSL v0.13.1 and v0.14.1 packages, they will patch out that check that pyOpenSSL's setup.py does (or perhaps pyOpenSSL will offer a "--affirm-heartbleed-fix-is-present" build-time option for this), in order for them to correctly send the signal that their Debian/Ubuntu "python-openssl 0.13.1" or "python-openssl 0.14.1" package does not have the vuln.

comment:14 Changed at 2014-05-12T22:39:52Z by zooko

Daira and I talked during today's Nuts And Bolts Party and agreed to make a minimal version of just the dynamic heartbleed vuln detector, ignoring version numbers and ignoring other vulns than heartbleed, and also to publish that as a separately-usable Python module.

comment:16 Changed at 2014-09-02T18:05:29Z by daira

  • Owner changed from zooko to daira
  • Status changed from new to assigned

I will review the current status of the branch.

comment:17 Changed at 2014-12-16T18:15:27Z by warner

Three options, not necessarily orthogonal.

  • 1: bundle a new version of openssl with pyopenssl
  • 2: require OpenSSL of at least 1.0.1j
  • 3: heroics: do some runtime check to determine whether our OpenSSL ("1.0.1j" or not) contains Heartbleed

1 requires coordination with the pyopenssl upstream folks: we're currently hosting eggs for this, but ideally we wouldn't be.

2 will probably cause build failures on some (debian) platforms that have patched the bug but not changed the version number

3 is hard, and can't be done for all the OpenSSL bugs we know about (some are very hard to detect at runtime).

comment:18 Changed at 2014-12-16T18:31:51Z by warner

BTW, current debian unstable (as well as testing aka "jessie") has OpenSSL 1.0.1j on most platforms:

https://packages.debian.org/search?keywords=openssl&searchon=names&suite=all&section=all

debian stable (aka "wheezy") has something named "1.0.1e-2+deb7u13", which self-reports as 1.0.1e but includes some number of security fixes.

If we used "2" and required an OpenSSL-reported version >= 1.0.1j, then build-from-source and dpkg would work fine on unstable, but build-from-source on stable would fail. We'd have full control of the error message, so we could provide pointers to either:

  • comment out / modify the version check to tolerate 1.0.1e
  • install a pyopenssl that includes a bundled OpenSSL-1.0.1j
  • install OpenSSL-1.0.1j from source (maybe to /usr/local) and somehow get pyopenssl to use it

I'm hesitant to embed an OpenSSL in pyopenssl in our tahoe-hosted eggs unless that's what the upstream pyopenssl folks want to do, or to depend upon having such a combination. I'm slowly becoming more comfortable with the idea of breaking some platforms if it means we can have simple version-detection code. If there were a simple heroic for Heartbleed, I'm ok with that too.

comment:19 Changed at 2015-01-22T17:13:00Z by zooko

  • Owner changed from daira to zooko
  • Status changed from assigned to new

comment:20 Changed at 2015-01-22T17:13:07Z by zooko

  • Status changed from new to assigned

comment:21 Changed at 2015-01-22T17:24:03Z by zooko

  • Keywords manual-test-needed added; review-needed removed
  • Owner changed from zooko to daira
  • Status changed from assigned to new

removing review-needed keyword

The next step is for Daira to test the heartbleed-detector on her own copy of openssl which she knows is patched to do heartbeat correctly (and is therefore invulnerable to heartbleed).

adding manual-test-needed keyword

comment:22 Changed at 2015-05-19T16:38:51Z by daira

  • Status changed from new to assigned

We decided to make tahoe --version[-and-path] include the self-reported version of the OpenSSL being used. This will be included in 1.10.1.

comment:23 Changed at 2015-06-02T17:15:28Z by daira

  • Priority changed from critical to major

comment:24 Changed at 2015-06-02T18:38:57Z by Daira Hopwood <daira@…>

In 96024d724438102661138fe2773f4c0c31fb671f/trunk:

Add OpenSSL version check and tests. refs ticket:2215

Signed-off-by: Daira Hopwood <daira@…>

comment:25 Changed at 2015-06-02T18:40:52Z by warner

  • Milestone changed from 1.10.1 to 1.11.0

Ok, since that part has landed, we can push the rest of this out into 1.11

comment:26 Changed at 2016-03-22T05:02:52Z by warner

  • Milestone changed from 1.11.0 to 1.12.0

Milestone renamed

comment:27 Changed at 2016-05-06T16:16:51Z by warner

  • Resolution set to somebody else's problem
  • Status changed from assigned to closed

Talking with marlowe today, we decided to WONTFIX this. If somebody has a clever talk-to-myself-and-discover-if-I'm-vulnerable tool, we can include it, but absent that, I think our best option is to mention heartbleed in the docs and tell folks that they need to upgrade their platform to have it fixed. Most linux distributions have fixed it by now, so it should really only be an issue for very old distributions, on which Tahoe is unlikely to run anyways.

Note: See TracTickets for help on using tickets.