All Heartbleed upgrades are now complete

By on April 9, 2014

Heartbleed

We have now completed all changes necessary to secure Bitbucket from security vulnerabilities related to the Heartbleed bug. Changes made to Bitbucket include;

As a result of us removing the sessions related to authentication cookies, all users have been forced to re-authenticate when using bitbucket.org from a browser. We are also recommending, but not enforcing, that all users change their passwords.

14 Comments

  • Justin Turner
    Posted April 9, 2014 at 1:21 pm | Permalink

    Thanks Atlassian / Bit Bucket.

  • Raghu
    Posted April 9, 2014 at 1:27 pm | Permalink

    now, onto 2FA!

  • Anonymous
    Posted April 9, 2014 at 1:45 pm | Permalink

    Speedy response – thanks very much.

  • Michal Mital
    Posted April 9, 2014 at 1:57 pm | Permalink

    Really quick response

  • Steven D'Anna
    Posted April 9, 2014 at 3:07 pm | Permalink

    Is there anything that Stash users need to do regarding Heartbleed?

    • Anonymous
      Posted April 10, 2014 at 7:53 pm | Permalink

      If you’ve configured your Stash instance to use SSL (HTTPS), especially with a 3rd-party proxy such as Apache or Nginx, you should check your OpenSSL library version.

    • Vitaly Osipov
      Posted April 10, 2014 at 8:23 pm | Permalink

      Not unless you’ve done something unusual. This is from http://blogs.atlassian.com/2014/04/openssl-cve-2014-0160-atlassian/ :

      Note: this comment applies only to standalone distributions, the ones that come with a built in web server.

      If you have followed our instructions on configuring SSL in any product (for example,https://confluence.atlassian.com/display/STASH/Securing+Stash+with+Tomcat+using+SSL), you are not using Tomcat’s APR and “native” OpenSSL libraries, but Java’s own implementation in javax.net.ssl. Java SSL does not even support hearbeats.

      If you scroll down that page, you will see that the config for APR OpenSSL is different. It includes directives such as SSLCertificateFile and SSLCertificateKeyFile.

      Moreover, Fisheye & Crucible installs Jetty instead of Tomcat. Jetty uses javax.net.ssl too.

      If you have installed a WAR distribution, then we are not handling SSL and the app container might be using host’s libraries. Again, if you configured the server not to use APR, you’re fine.

  • Luke
    Posted April 10, 2014 at 10:14 am | Permalink

    We should also generate new keys for access to our Bitbucket repositories via SSH, right?

    • Posted April 10, 2014 at 12:57 pm | Permalink

      As with changing your password, that’s up to you.

      • Guest
        Posted April 11, 2014 at 9:07 am | Permalink

        Is it also recommended, as with changing our passwords?

    • Vitaly Osipov
      Posted April 10, 2014 at 8:22 pm | Permalink

      Your SSH keys are safe – the whole idea of the public key encryption is that your private key stays on your computer and public keys are, well, public.

  • Anonymous
    Posted April 10, 2014 at 1:23 pm | Permalink

    We’re using rbcommons with a bitbucket repository. Today when we try to upload a diff to rbcommons, we get “The file XYZ (xyz) could not be found in the repository” — is there something we need to update at bitbucket or rbcommons?

  • Posted April 23, 2014 at 1:52 am | Permalink

    The words “heartbleed bug” in this post are a link to nowhere.

    TRiG.

  • Daniel Missiler
    Posted April 23, 2014 at 6:25 am | Permalink

    Tested right now bitbucket.org with http://www.first-security.com/de/heartbleed and all looks fine. Thanks for solving the vulnerability fast!