mitigate heartbleed vulnerability

[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).

[daira]

Also see ​http://foolscap.lothar.com/trac/ticket/220.

[daira]

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.)

[zooko]

I've reviewed ​https://github.com/tahoe-lafs/tahoe-lafs/commit/e8ab8a7487489f84c3d474469127830f9d67e74b and ​https://github.com/tahoe-lafs/tahoe-lafs/commit/e22adb5edd41786b3498d6ab4040ee47ae4c4b95 . Looks good to me!

[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.

[daira]

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

[daira]

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.

[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.

[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.

[zooko]

Opened ​https://github.com/pyca/pyopenssl/issues/95

[zooko]

Work in progress: ​https://github.com/tahoe-lafs/tahoe-lafs/commits/2215-refuse-vulnerable-openssl-2

[zooko]

I've posted a couple of comments so far: ​https://github.com/tahoe-lafs/tahoe-lafs/commit/9393f1ea2d6bf9d555ac29d4658efde73b334c45#commitcomment-6073640

[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.

[zooko]

Ivan Ristic's heartbleed-detector patch:

​https://github.com/ivanr/bulletproof-tls/tree/master/heartbleed

[daira]

I will review the current status of the branch.

[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).

[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.

[zooko]

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

[daira]

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.

[Daira Hopwood <daira@…>]

In 96024d724438102661138fe2773f4c0c31fb671f/trunk:

Add OpenSSL version check and tests. refs ticket:2215

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

[warner]

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

[warner]

Milestone renamed

[warner]

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.