You have probably already heard about the OpenSSL vulnerability, named Heartbleed, that is getting so much attention in the press. This is a significant vulnerability that can expose data in memory on your server. Making matters worse is that this vulnerability leaves absolutely no trace on the server. You will not see this in your logs no matter how detailed your logging level and it also does not require any authentication with the server.
This bug impacts the current Subversion binaries we were providing so we have updated those binaries to include the fixed version of OpenSSL – 1.0.1g and those updates are available now.
For Subversion Edge users, you can get these via the in-app updates. The Subversion Edge version is now 4.0.6. For the regular binaries the version is still 1.8.8 but the package names are 1.8.8-2.
WHO NEEDS THIS UPDATE
This update is only needed on a Subversion server that is using the Apache httpd server and SSL. While you can update your clients if you want to,
the client is not vulnerable to this bug and the client does not have to be updated as part of resolving this issue on your server. UPDATE: There are apparently scenarios being discussed where a server could send the same requests to a client to steal information from the client machines memory. So if you are running a client that uses OpenSSL 1.0.1 it is recommended to update it as well. The binaries linked above also included updated clients, so we have already posted the updates you need.
Only servers that are using OpenSSL 1.0.1 through 1.0.1f are vulnerable. The easiest way to check your version is to look in your Apache httpd error_log. When Apache starts, it prints out a line like this in that log file:
[Tue Apr 08 10:56:06.087918 2014] [mpm_winnt:notice] [pid 2192:tid 328] AH00455: Apache/2.4.9 (Win64) SVN/1.8.8 OpenSSL/1.0.1g configured — resuming normal operations
As you can see, this message contains the version of Apache httpd, Subversion and most importantly in this case, OpenSSL. The fixed version is 1.0.1g.
If your server is using 0.9.8 or 1.0.0 then you are NOT vulnerable and you do not have to update. The above approach is the best way to determine the version you are using, but if you cannot check the logs, then in terms of the binaries we provide, we started using OpenSSL 1.0.1 on Windows with Subversion 1.8.0 and on Linux and Solaris only since the 1.8.8 and 1.7.16 released back in February of this year. So if you are on older versions of Subversion then you are probably using OpenSSL 0.9.8 currently and would not be vulnerable to this attack.
It is worth noting that there are good reasons to move to OpenSSL 1.0.1, namely so that TLS 1.1/1.2 can be used which helps mitigate against the BEAST attack.
WHAT ELSE SHOULD YOU DO
This is where things get more tricky. Because it is impossible to know if your existing server has been compromised, the recommendation is to act as if it has been. Most sites recommend that AFTER you have patched your server, the next step should be to revoke the current SSL certificate it is using and generate a new certificate from a new key pair. It is important that you generate a new key pair because the problem you are trying to resolve
is if your private key was stolen.
The other recommendation is to change all user passwords because those could have also been compromised. If your SVN server is attached to your corporate LDAP or Active Directory, that would mean the passwords used by those services may have been compromised and should be changed.
If you share these concerns, it is imperative that you first patch your server, then fix the SSL cert and only then change the passwords.