Heartbleed: dovecot2 is still vulnerable after upgrade of OpenSSL library

[Clemens Lang]

Hi,

> thank you for your quick response. But I’m not sure whether you are right.
> 
> I forced a rebuild of first the OpenSSL library  and then of dovecot. I
> already posted the result. According to your proposition this should have
> solved the issue. But it didn’t.

I looked at the dovecot package and found a couple of static libraries that
seemed to be SSL-related and thought that might have been the problem in this
case. Specifically /opt/local/lib/dovecot/libssl_iostream_openssl.a seems to
use symbols from openssl [1]. A closer look however, reveals that the file
doesn't actually contain any code from OpenSSL, just a couple of unresolved
symbols [2].

All these static libraries can also be build as dynamically linked shared
modules, which I thought would fix the problem. I filed #43436 [3] to request
that and it was committed meanwhile. However, I failed to reproduce your test
results with both 2.2.12_0 (the version built by the buildbot 6 weeks ago when
openssl was still vulnerable) and 2.2.12_1 (the version after I forced a
rebuild in r119239 [4]):

$> ./cardiac-arrest.py -p 993 127.0.0.1
[INFO] Testing: 127.0.0.1
[INFO] Connecting to 127.0.0.1:993 using SSLv3
[INFO] No heartbeat response was received. The server is probably not vulnerable.
[INFO] Connecting to 127.0.0.1:993 using TLSv1.0
[INFO] No heartbeat response was received. The server is probably not vulnerable.
[INFO] Connecting to 127.0.0.1:993 using TLSv1.1
[INFO] No heartbeat response was received. The server is probably not vulnerable.
[INFO] Connecting to 127.0.0.1:993 using TLSv1.2
[INFO] No heartbeat response was received. The server is probably not vulnerable.
[PASS] 127.0.0.1:993 does not appear to be vulnerable to Heartbleed!


So it seems that the changes I made (in [4]) and requested to be made (in [3])
were actually unnecessary and I overreacted.


Now, that leaves me to explain why your installation is apparently still
affected, even after a rebuild with the fixed openssl version active. Static
linking cannot explain this [5] (contrary to what I thought at first), because the
rebuild would have fixed it. The library must be dynamically loaded in a
vulnerable version.

How do you start dovecot? What does `env | grep DYLD_` print on your system?
What's the output of `sudo env DYLD_PRINT_LIBRARIES=1 dovecot -F` on your system?
Do you have files matching libssl*.dylib or libcrypto*.dylib in /usr/local/lib?


[1] port contents dovecot2 | grep -E '\.(dylib|a)$' | while read file; do if nm -u $file 2>/dev/null | grep SSL &>/dev/null; then echo $file; fi; done
[2] nm -u /opt/local/lib/dovecot/libssl_iostream_openssl.a | grep '_SSL'
[3] http://trac.macports.org/ticket/43436
[4] http://trac.macports.org/changeset/119239
[5] unless you replaced your version of /usr/lib/lib{crypto,ssl}* with a
    vulnerable version manually or have a vulnerable version in /usr/local/lib.

-- 
Clemens Lang