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
Received on 2014-04-13 04:08:11 CEST