report from this week's Nuts And Bolts party

Zooko Wilcox-OHearn zooko at leastauthority.com
Tue Jun 3 19:13:55 UTC 2014


.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

=======================================
 LAFS Nuts And Bolts Party, 2014-06-02
=======================================

in attendance: Zooko (scribe), Daira, dreid (sort of present)

topic: the Heartbleed Detection Patch (#2215 and #2222)

https://github.com/tahoe-lafs/tahoe-lafs/blob/b521ff0b33aaa3aff0431ff1944bc3fad4923101/src/allmydata/util/check_pyopenssl.py

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2222

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2215

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2215#comment:14

Daira doesn't agree with Zooko that Tahoe-LAFS should ignore OpenSSL
version numbers and do solely the active test. She doesn't agree because
she doesn't trust the active test to be accurate in both
no-false-positives and no-false-negatives directions. In particular, the
current test code, run against the current OpenSSL (v1.0.1g) from her
Debian-derived Linux distro, finds that OpenSSL emits *no* heartbeat
responses at all, even in response to well-formed (non-attacking)
heartbeat queries. What gives? Did Debian compile heartbeat support out
of OpenSSL?

Here's some text that Zooko wrote into a potential new README.rst file
for the potential new "heartbleed-detector" tool. This text is not (yet‽)
true.


heartbleed-detector -- see if your pyOpenSSL comes with the heartbleed
vulnerability
====================================================================================

heartbleed-detector uses pyOpenSSL to test its openssl implementation for
heartbleed. It does this by actually attempting to exploit the heartbleed bug
(i.e., it sends 1-byte heartbeat message along with a bogus "payload length =
4096"), so we do not expect it to give false negatives nor false alarms.

That is: if it prints out "THIS OPENSSL LIBRARY IS VULNERABLE TO HEARTBLEED."
then we are pretty confident that the vulnerability really is present in that
particular OpenSSL library (i.e., the OpenSSL library returns a buffer
containing more than one byte of data in the payload). If it prints out "This
OpenSSL library is not vulnerable to heartbleed.", then we are pretty
confident that the vulnerability really is absent from that particular
OpenSSL library (i.e. either it ignores the heartbeat request, or it returns
a buffer containing exactly one byte of data in the payload).

If it doesn't print out either of those things, then there is a different
bug, either in heartbleed-detector, in pyOpenSSL, or in OpenSSL, so please
open a bug report and paste in whatever traceback or other output it
produced.

heartbleed-detector has been tested with pyOpenSSL v0.13 and v0.14.



More information about the tahoe-dev mailing list