Heartbleed can be used to leak arbitrary memory from the server to the client, undetectably.
As a test, I just sent a copy of my previous message through a server running SurgeMail 6.6a on SmartOS. I then ran the ssltest.py test exploit against the same server. Here is just a fragment of the information that the script was able to obtain from the server, WITHOUT ANY FORM OF AUTHENTICATED CONNECTION WHATSOEVER. (Excuse the caps.)
0f00: 54 72 61 6E 73 66 65 72 2D 45 6E 63 6F 64 69 6E Transfer-Encodin
0f10: 67 3A 20 71 75 6F 74 65 64 2D 70 72 69 6E 74 61 g: quoted-printa
0f20: 62 6C 65 0D 0A 43 6F 6E 74 65 6E 74 2D 54 79 70 ble..Content-Typ
0f30: 65 3A 20 74 65 78 74 2F 70 6C 61 69 6E 3B 0D 0A e: text/plain;..
0f40: 09 63 68 61 72 73 65 74 3D 77 69 6E 64 6F 77 73 .charset=windows
0f50: 2D 31 32 35 32 0D 0A 0D 0A 53 74 65 66 66 65 6E -1252....Steffen
0f60: 2C 0D 0A 0D 0A 41 46 41 49 43 53 20 53 75 72 67 ,....AFAICS Surg
0f70: 65 4D 61 69 6C 20 69 73 20 73 74 61 74 69 63 61 eMail is statica
0f80: 6C 6C 79 20 6C 69 6E 6B 65 64 20 74 6F 20 4F 70 lly linked to Op
0f90: 65 6E 53 53 4C 2C 20 61 74 20 6C 65 61 73 74 20 enSSL, at least
0fa0: 6F 6E 20 4F 53 20 58 20 61 6E 64 20 3D 0D 0A 53 on OS X and =..S
0fb0: 6F 6C 61 72 69 73 20 78 36 34 2C 20 63 66 2E 20 olaris x64, cf.
0fc0: 61 6C 73 6F 20 74 68 65 20 72 65 6C 65 61 73 65 also the release
0fd0: 20 6E 6F 74 65 20 6F 6E 20 76 65 72 73 69 6F 6E note on version
0fe0: 20 36 2E 36 62 2D 39 2E 20 28 45 78 70 65 72 69 6.6b-9. (Experi
0ff0: 6D 65 6E 74 61 6C 20 3D 0D 0A 57 69 6E 64 6F 77 mental =..Window
1000: 73 20 62 75 69 6C 64 20 77 69 74 68 20 4F 70 65 s build with Ope
1010: 6E 53 53 4C 20 31 2E 30 2E 31 66 2E 29 0D 0A 0D nSSL 1.0.1f.)...
1020: 0A 42 75 74 20 65 76 65 72 79 20 70 6C 61 74 66 .But every platf
1030: 6F 72 6D 20 61 70 70 65 61 72 73 20 74 6F 20 68 orm appears to h
1040: 61 76 65 20 61 20 64 69 66 66 65 72 65 6E 74 20 ave a different
1050: 76 65 72 73 69 6F 6E 2C 20 70 72 65 73 75 6D 61 version, presuma
1060: 62 6C 79 20 3D 0D 0A 77 68 61 74 65 76 65 72 20 bly =..whatever
1070: 69 73 20 77 65 6C 6C 2D 73 75 70 70 6F 72 74 65 is well-supporte
1080: 64 2E 20 49 20 74 65 73 74 65 64 20 53 75 72 67 d. I tested Surg
1090: 65 4D 61 69 6C 20 36 2E 36 61 20 6F 6E 20 4F 53 eMail 6.6a on OS
There is a lot more, some of it obviously more sensitive than this, and this can absolutely leak critical private SSL key information, at least unless NetWin has taken unusual measures to prevent that. It can basically leak anything at all.
This is extremely serious shit.
Best,
Chris
Wait. What are are these confirmed reports of leaked information? What's being leaked?
On 4/8/2014 4:37 PM, Frank Bulk wrote:
How does that information jive with the confirmed reports that Surgemail is leaking information?
Frank
-----Original Message-----
From: Steffen [mailto:steffen@land10.nl]
Sent: Tuesday, April 08, 2014 3:12 PM
To: surgemail-list@netwinsite.com
Subject: Re: [SurgeMail List] CVE-2014-0160 a. k. a.Heartbleed
Current OpenSSL version of Surgemail is 0.9.8r.
OpenSSL 0.9.8 branch is NOT vulnerable.
Steffen
On Tuesday 08/04/2014 at 21:59, Peter Dyke wrote:
Interestingly enough, when using the self-signed cert,
SurgeMail Version 6.5b-13, Built Oct 17 2013 08:35:02, Platform
Linux_64
simply does not run the Heartbleed test script, instead returns
dial tcp 143.*.*.*:443: connection refused
(IP address redacted)
On 4/8/2014 12:29 PM, Chris Ferebee wrote:
It’s a doozy all right. There’s a nice overview at
<https://maclemon.at/blog/2014/04/07/openssl-heartbeat-cve-2014-0160/>
with links to some sample exploits as python scripts. You can run them
(non-destructively) against your SurgeMail server to see what they
turn up. I saw a bunch of sensitive information when I tried it
earlier today. It is perfectly possible that this can be exploited to
divulge your SSL private keys. We will all need to revoke our
certificates and order new ones once we’re patched. It might be
appropriate to issue new mail passwords.
If you can install your certs on your load-balancer and proxy the SSL
traffic, yes, that seems like it would help, as long as your
load-balancer is not vulnerable.
Best,
Chris
Am 08.04.2014 um 21:00 schrieb Frank Bulk <fbulk@mypremieronline.com>:
When I reviewed the issue last night I wasn't overly concerned,
thinking this was more MiTM attack, but after reviewing
http://heartbleed.com/ more carefully, it seems like they could
potentially walk through memory in 64 kilobyte chunks and retrieve
other content.
Can we get some new binaries yet today?
Is the temporary mitigation to use SSL from the load-balancer in front
of our two Surgemail servers?
Regards,
Frank
-----Original Message-----
From: Chris Ferebee [mailto:cf@ferebee.net]
Sent: Tuesday, April 08, 2014 6:46 AM
To: surgemail-list@netwinsite.com
Subject: [SurgeMail List] CVE-2014-0160 a. k. a. Heartbleed
ChrisP, Marijn,
When you have a moment, could you please let us know what the status
of SurgeMail is WRT the CVE-2014-0160 a. k. a. Heartbleed SSL exploit?
I have a server running SurgeMail 6.6a on a version of SmartOS
(Solaris x64) with OpenSSL 1.0.1e installed, and it is vulnerable as
per
<http://filippo.io/Heartbleed/>
and other example exploits. A different server running SurgeMail 6.6a
on OS X 10.6.8 (which includes OpenSSL 0.9.8y) is not vulnerable.
However, as far as I can tell, SurgeMail does not dynamically link
OpenSSL from the host platform in either case and therefore presumably
comes with its own, statically linked version.
Therefore, it appears that we urgently need a fixed version of
SurgeMail, e. g. 6.6a, in my case for Solaris x64, presumably also for
some of the other platforms. Do you have an ETA for that yet?
Best,
Chris
