Subversion and Heartbleed — Are you vulnerable?

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.

http://www.collab.net/downloads/subversion

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.

Mark Phippard

Engineering manager for several teams at CollabNet, including CloudForge, Subversion, Subversion Edge, Git and our Desktops and Integrations. Project owner for the Subclipse project, which provides Subversion support in Eclipse. Also a full committer for the Subversion project. Product owner for GitEye, Subversion Edge and the CollabNet Desktops and Integrations.

Tagged with: ,
Posted in Subversion
9 comments on “Subversion and Heartbleed — Are you vulnerable?
  1. Morad says:

    Dumb question, but how do you revoke and SSL certificate?

    • Mark Phippard says:

      It is not a dumb question.

      This is a weak area of SSL in general. If you obtained your certificate from a Certificate Authority, then you would ask them to revoke it. Honestly, this is the only scenario where the feature sort of works.

      See:
      http://en.wikipedia.org/wiki/Revocation_list
      http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html

      Note that SVN clients do not support certificate revocation, so they will not warn user if it connects to a server with a revoked cert. Some web browsers do however, so you could tell users to visit the repos with a browser first and let it verify the cert.

      If you are using a self-signed cert, I am not really sure if there is anything you can realistically do to revoke a cert. The above links might help though.

      • Morad says:

        It’s pretty obvious I don’t really know what I’m doing, so I really appreciate you taking the time to answer my quesiton!

        My institution notified me of 2 heatbleed attacks on my machine on April 10th. I reinstalled Subversion Edge (verified that it’s using 1.0.1g), and changed all my passwords. The network admin said I had to revoke any certificates, but I didn’t know how which is why I asked. I don’t recall ever having issued a certificate, or for that matter ever having to deal with a certificate.

        I found a certificate in C:\csvn\data\certs, but I don’t know if that has anything to do with it. If I uninstall Subversion Edge, will I need to worry about anymore attacks? I know you’re busy, so thanks a lot!

        • Mark Phippard says:

          > If I uninstall Subversion Edge, will I need to worry about anymore attacks?

          Let’s start here. Do you need to be running an Apache Subversion server? If so, then I do not see how uninstalling Subversion Edge is relevant question. You either need this server or you do not. If you do not, then absolutely go ahead. You do not even have to uninstall right now, just stop the 2 Windows Services and set their startup to Manual. That will make it easier to reenable it if you messed up in thinking you do not need this.

          In terms of the cert, it sounds like you are using the self-signed cert that comes with SVN Edge. There is no reason to try to revoke that cert because it is not really secure anyway. The data is encrypted but if you are really concerned about people doing something with that info, the private key can be retrieved anyway.

          There is documentation here on replacing the default certificate with your own:

          https://ctf.open.collab.net/sf/wiki/do/viewPage/projects.svnedge/wiki/SSL

          You would have to purchase a cert or generate your own new one. The latter would be easier.

          The idea behind changing the cert is that if someone has your private key, they could stand up a man-in-the-middle attack where they use your key to pretend to be your server and the user connecting would never know. Since you cannot revoke the cert and most users are just going to blindly accept any key anyway, it does not buy you a lot of extra security to do anything here about the cert unless you are really concerned about this scenario.

          Mark

          • Morad says:

            I need the SVN server to commit to my code to my repository and I’m the only one who needs access to it. My colleague suggested it to me a couple of years ago so that I can work from home, and I’ve been using it ever since.

            I only access the server via my SVN client, or the browser when I need to login and stop the server. I’m not really worried about attackers seeing my code, I’m just worried they’ll get my password and find out other information about me, or do something nefarious to my machine.

            I’m using the self-signed certificate that came with Subversion Edge. Did uninstalling and reinstalling give me a new cert (I’m an inexperienced user)? I think the biggest issue I’m having is understanding certificates and how it pertains to securing my system. At the risk of sounding even dumber, if I edit server.key (in data/conf) will attackers who’ve compromised my key before still have access?

            If nothing else, I’ll just stop the service and start it only when I need to commit. :\ Thanks!

          • Mark Phippard says:

            > I’m not really worried about attackers seeing my code
            > I’m just worried they’ll get my password and find out other
            > information about me, or do something nefarious to my machine

            It is possible someone already got your password, which is why you should change it. But now that you updated, it should be safe. The problem with the SSL cert would happen only if they could stand up a server in between your client and server. I would not be worried about that because to be honest, based on your questions, if someone were to do this, I would guess you would get snagged by this even if they did not have your cert.

            > I’m using the self-signed certificate that came with Subversion Edge. Did uninstalling and reinstalling give me a new cert

            No. It will still be using the same cert it was before.

            > if I edit server.key

            You cannot “edit” a certificate. You would have to generate a new one. It is not hard. Just run command like this and fill out the prompts:

            openssl req -x509 -newkey rsa:2048 -nodes -keyout server.key -out server.crt -days 720

            Then copy the server.key and server.crt files to your C:\csvn\data\conf folder.

            > will attackers who’ve compromised my key before still have access

            Hackers do not have access to your server with or without the key. The issue is that if they have your key and can capture your traffic then they can decrypt it using the key and get your password out of the data sent over the wire. If you change the key, that cannot happen.

  2. Morad says:

    So I generated a new key and cert, and put it in the appropriate directory. I’m going to go through and change all of my passwords again, but I’m hoping this is the last I’ll have to deal with this.

    Thanks a lot for taking the time to answer my questions! Hopefully this helps other people. 🙂

  3. Rachael says:

    I am trying to load the updates for the heartbleed vulnerability. When I select Install Updates, the screen just sits at Initial Phase and nothing happens. How do I go about getting the updates to load?

Leave a Reply

Your email address will not be published. Required fields are marked *

*