On Sat, Apr 12, 2014 at 10:08 PM, Ben Reser <breser_at_apache.org> wrote:
> This specific issue lies in the implementation of a feature of the SSL/TLS
> protocols. Apache HTTP Servers running mod_ssl to provide SSL/TLS are
> vulnerable. While svnserve does support encryption via Cyrus SASL, and Cyrus
> SASL does use OpenSSL to provide the encryption algorithms, it does not use it
> to implement the SSL/TLS protocols. This means that svnserve is not directly
> vulnerable. However, you can use the svnserve over tunnels and those tunnels
> may be vulnerable. For instance stunnel implements the SSL/TLS protocol and
> does so via OpenSSL. SSH based tunnels are unaffected as they do not use the
> SSL/TLS protocols. If you're using some other tunnel not mentioned here you
> should check with the developers of that tunnel for details.
>
> It is important to understand that this vulnerability is not specific to the
> server side. Clients can be vulnerable to malicious servers using the same
> attack against clients. So care should be taken to ensure that clients are not
> using vulnerable OpenSSL versions as well.
Thank you, Ben. In all the furor about the bug, the publicly available
"heartbleed" test tools all seem to be test only https://, not
http://, and I've not seen the client vulnerability you mention
discussed at all. Do you have anything a bit more authoritative about
the "httpd servers with mod_ssl loaded are also vulnerable over plain
http://" ? I believe you, I'm just trying to make sure when I bring
this up at work that I don't have to spend an hour explaining the
details of httpd configuration and loadable modules.
I'm assuming that the vulnerability for particular httpd (Apache 2.x)
web servers is *only* activated when the "mod_ssl" module is loaded,
or other similar encryption modules. I'm afraid that I've also seen
people who believe they're immune because they route all oficial
traffic through an SSL proxy, and the SSL proxy is safe. But the
internal server the proxy connects to supports *both* HTTP and HTTPS,
so it has mod_ssl loaded, and is thus vulnerable to *internal* attack.
That' would be true even if the external proxy blocks such attacks.
I've not seen any verification that proxies set for simple HTTP
pass-through are vulnerable. I suspect they're safe, but I'd really
like to have a test tool to verify this. Has anyone seen a Heartbleed
test tool that will test HTTP sites, or HTTPS on ports other than 443?
Especially one that can be run from an iPhone 4 like mine, or
downloaded and run on a local Linux system? I've seen the Android tool
already in use.
Make no mistake, this is a big risk for entire environments: Stolen
Subversion access alone can often provide access to internal software
or site configuration tool repositories such as Puppet or CFengine, or
software build environments and source trees for sensitive software.
One someone has been sniffing important passwords from one exposed
server, they may be able to use those for access through your VPN or
external SSH jumpgates and go rooting around your much less secured
internal systems. Worse: many sites use their AD or LDAP based
credentials for VPN access, for SSH login access to home directories
with NFS acess to other people's accounts, and for internal "sudo"
access. So those exposed passwords may also provide far, far more
internal exposure. Couple such VPN access with internal NFS, which
only rarely uses the Kerberos enabled NFSv4 settings and an attacker
has visibility into stored Subversion passwords in NFS home
directories or un-passphrase protected SSH keys in NFS home
directories. That.... gets *nasty*.
The SSL key theft, and possible site forgery or Man-in-the-Middle
attacks, have gathered a lot of the attention of the HeartBleed bug.
But the password theft risks are much more awkward to clean up in a
quick sweep.
Nico Kadel-Garcia
Received on 2014-04-13 13:22:05 CEST