mitigate heartbleed vulnerability #2215

New Issue

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 commented

2014-04-10 18:06:28 +00:00

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!

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 commented

2014-04-11 16:22:01 +00:00

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.

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 commented

2014-04-11 16:22:54 +00:00

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

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

daira commented

2014-04-12 10:50:31 +00:00

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.

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 was assigned by tahoe-lafs

2014-04-12 10:51:55 +00:00

zooko commented

2014-04-15 16:30:32 +00:00

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 commented

2014-04-15 17:41:54 +00:00

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.

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/2215#issuecomment-94745): > 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 commented

2014-04-15 17:44:01 +00:00

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

Opened <https://github.com/pyca/pyopenssl/issues/95>

zooko commented

2014-04-21 21:11:22 +00:00

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

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

zooko commented

2014-04-21 22:07:48 +00:00

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

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

zooko commented

2014-05-12 22:39:52 +00:00

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 commented

2014-07-18 13:11:22 +00:00

Ivan Ristic's heartbleed-detector patch:

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

Ivan Ristic's heartbleed-detector patch: <https://github.com/ivanr/bulletproof-tls/tree/master/heartbleed>

daira commented

2014-09-02 18:05:29 +00:00

I will review the current status of the branch.

warner commented

2014-12-16 18:15:27 +00:00

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

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 commented

2014-12-16 18:31:51 +00:00

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.

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 commented

2015-01-22 17:24:03 +00:00

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

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 commented

2015-05-19 16:38:51 +00:00

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.

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.

tahoe-lafs added

major

and removed

critical

labels 2015-06-02 17:15:28 +00:00

Daira Hopwood <daira@jacaranda.org> commented

2015-06-02 18:38:57 +00:00

In /tahoe-lafs/trac-2024-07-25/commit/96024d724438102661138fe2773f4c0c31fb671f:

Add OpenSSL version check and tests. refs ticket:2215

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

In [/tahoe-lafs/trac-2024-07-25/commit/96024d724438102661138fe2773f4c0c31fb671f](/tahoe-lafs/trac-2024-07-25/commit/96024d724438102661138fe2773f4c0c31fb671f): ``` Add OpenSSL version check and tests. refs ticket:2215 Signed-off-by: Daira Hopwood <daira@jacaranda.org> ```

warner commented

2015-06-02 18:40:52 +00:00

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

warner modified the milestone from 1.10.1 to 1.11.0

2015-06-02 18:40:52 +00:00

warner commented

2016-03-22 05:02:52 +00:00

Milestone renamed

warner modified the milestone from 1.11.0 to 1.12.0

2016-03-22 05:02:52 +00:00

warner commented

2016-05-06 16:16:51 +00:00

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.

warner added the

somebody else's problem

label 2016-05-06 16:16:51 +00:00

warner closed this issue

2016-05-06 16:16:51 +00:00

Sign in to join this conversation.