You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Reser <br...@apache.org> on 2014/04/13 04:08:55 UTC
Subversion and Heartbleed
As you may have heard in the news OpenSSL has had a significant security
vulnerability [1] [2]. Subversion by way of several of our dependencies uses
OpenSSL. On the client side the Neon and Serf HTTP libraries can use OpenSSL
(Neon can also use GNUTLS, which is not vulnerable to this issue) and on the
server side Apache HTTP Server and Cyrus SASL can use OpenSSL (though Cyrus
SASL's use of OpenSSL is not vulnerable).
As a result it is important to make sure that the OpenSSL version being used
with Subversion is not vulnerable. It is impossible for the Subversion project
to provide vulnerable version information for Subversion since if you are
vulnerable depends on the OpenSSL used at build and/or run time. We do not
publish binaries, so you should consult with your binary provider to make sure
you are not vulnerable. If you've built your own version of Subversion you
should check which version you have built against and/or are using at runtime.
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.
The unfortunate consequence of this vulnerability is that server or client
memory may be exposed to the other side of the connection. This has the
possibility of exposing private information that the other side of the
connection should not have. Within the context of Subversion that means
authentication information, details about working copies, data from other
clients, private keys used with public key encryption, etc.
As a result of the above potential data disclosures, after you have upgraded to
non-vulnerable versions of the software, you may want to take additional
actions including revoking and reissuing SSL/TLS server and client certificates
and resetting user passwords. It is understood that retrieving private keys to
certificates may be very difficult, but still possible. Other data may be much
easier to retrieve. As such, if these steps are necessary are largely a matter
of your risk tolerance.
If you are using HTTPS to access your Subversion repositories and do decide to
revoke your certificates you should understand that at current Subversion does
not support rejecting revoked certificates that would otherwise be trusted.
Our HTTP libraries (Neon and Serf) which we depend on for this sort of
functionality do not currently provide support for providing an external CRL
(Certificate Revocation List), retrieving CRLs from a URL in the certificate,
checking certificates via OCSP (Online Certificate Status Protocol) or handling
an OCSP response that has been stapled to the TLS handshake.
In the meantime, you can disable trusting certificates based on trust in the
Certifying Authorities to avoid accepting revoked certificates. To do this you
will want to make some configuration changes in your server config file for
Subversion (usually at /etc/subversion/servers, ~/.subversion/servers, or
%APPDATA%\Subversion\servers, see [3] for more details). Set
"ssl-trust-default-ca" to "no" and remove the "ssl-authority-files" setting.
By doing this Subversion will prompt for all certificates giving you details on
the certificate and a fingerprint. You will then have the opportunity to
accept the certificate temporarily or permanently. Server admins should let
their users know the fingerprints of the correct certificates. This is similar
to the manner in which SSH handles validating they are talking to the server
they expect to be.
If you have already trusted certificates that are now revoked you will also
need to remove them from your authentication store for Subversion. This will
be stored under ~/.subversion/auth/svn.ssl.server or
%APPDATA%\Subversion\auth\svn.ssl.server. You can delete the entire directory
to remove all accepted certificates or just delete specific files within the
directory to remove just those certs. The files are simply text files
containing some data, you should be able to read them to locate the specific
keys you which to remove.
We realize that the handling for revoked certificates is far from ideal at this
time. We plan to improve this in the future, but are unable to provide a time
frame for such improvements.
[1] http://www.openssl.org/news/secadv_20140407.txt
[2] http://heartbleed.com/
[3] http://svnbook.red-bean.com/en/1.8/svn.advanced.confarea.html
Re: Subversion and Heartbleed
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Apr 13, 2014 at 07:21:26AM -0400, Nico Kadel-Garcia wrote:
> I'm assuming that the vulnerability for particular httpd (Apache 2.x)
> web servers is *only* activated when the "mod_ssl" module is loaded,
Yes. The server must perform TLS negotiation using a vulnerable
OpenSSL version. Data leaked via heartbleed can come from unrelated
connections handled by the same server process, whether or not those
other connections use TLS.
> 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?
There are published test scripts. You can edit them and change the port.
E.g. https://github.com/musalbas/heartbleed-masstest/blob/master/ssltest.py
will do what you want if you adjust the port number (and perhaps
simplify the argument processing such that the script probes a
single server specified on the command line).
Re: Subversion and Heartbleed
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Apr 13, 2014 at 07:21:26AM -0400, Nico Kadel-Garcia wrote:
> I'm assuming that the vulnerability for particular httpd (Apache 2.x)
> web servers is *only* activated when the "mod_ssl" module is loaded,
Yes. The server must perform TLS negotiation using a vulnerable
OpenSSL version. Data leaked via heartbleed can come from unrelated
connections handled by the same server process, whether or not those
other connections use TLS.
> 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?
There are published test scripts. You can edit them and change the port.
E.g. https://github.com/musalbas/heartbleed-masstest/blob/master/ssltest.py
will do what you want if you adjust the port number (and perhaps
simplify the argument processing such that the script probes a
single server specified on the command line).
Re: Subversion and Heartbleed
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sat, Apr 12, 2014 at 10:08 PM, Ben Reser <br...@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
Re: Subversion and Heartbleed
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sat, Apr 12, 2014 at 10:08 PM, Ben Reser <br...@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