July 1, 2014

New OpenSSL vulnerabilities = New SpiderOak client

by with 10 comments

On June 5, a new set of vulnerabilities were disclosed in OpenSSL.

Everybody should update to either 0.9.8za or 1.0.1h, regardless of how you use it. This set of bugs affect both server side and client side software in quite interesting ways, but we’ll leave the gory details for another time.

The important point today is that we’ve updated all of our servers as soon as we heard the news, and we promptly started working on a new release for the SpiderOak desktop client.

We are a lot farther away from June 5 than we would want. Luckily the set of vulnerabilities released, along with how the SpiderOak desktop client works, doesn’t make this a blocker. But we’ve already figured out how to improve the release process for the next set of (still unknown) OpenSSL vulnerabilities.

Please be sure to click here and download the latest client for your platform.

Moving forward

We are living in an interesting time. Even though it might seem a bit frightening to need to update such key pieces of software so frequently, the important side of this is that the core of the internet is getting safer and more robust.

Sign up for updates on our blog below, so you can stay up to date and as secure and private as possible.

  1. Frightening time you say? For me it was Tuesday.

    Seriously though, people like myself and you fine people at SpiderOak just upgraded packages and *maybe* got new certs depending on machine conditions and moved on. Bugs get found, bugs get fixed, cleanups happen (which openssl is long overdo for. Looking forward to switching to libressl since we already know it won’t get merged).

  2. Having improved the release process is great news. Sadly, vulnerabilities are a fact of life, and being able to quickly roll out a new secure version in response is important. Great job!

    Typo: Last para, “bellow” should probably be “below”.

  3. I am a bit confused by the line “Everybody should update to either 0.9.8za or 1.0.1h”.
    I am currently showing version 5.1.3 in the GUI, and 5.1.5 from the command line (Fedora 20 x86_64):

    $> SpiderOak –version
    SpiderOak v5.1.5.10100

    What version should I be using to ensure that I am protected?

    • Sorry, a quick restart of the GUI brought the displayed version up to date. I had performed updates since the GUI had started… =) The question still stands though…

      • I got confused by that too for a moment; then realized they are talking about OpenSSL, so shoud’ve read: “Everybody should update _OpenSSL_ to either 0.9.8za or 1.0.1h”

  4. I got the update to 5.1.5 yesterday through my distro. (Not sure why I didn’t get it through SpiderOak’s update?)

    However, I’ve had to downgrade to 5.1.3 since it is not picking up synced changes. In particular, it doesn’t sync changes *from* the cloud but only *to* the cloud. At least, that’s certainly the situation on my laptop. (GNU/Linux 3.15.2 x86_64.)

    So now I’m nervous. Is there any work around for this bug or am I stuck using the insecure version?

    Incidentally, it isn’t really correct to say everyone should make sure to be using one of those versions of the library since many distros will backport security fixes rather than rolling out updates which might include other changes. (My laptop has the 1.0.1.h version but many people might be perfectly safe without an updated *version* provided the patches have been back ported.)

    • I’m sorry to hear you’re having trouble with the new version. Please do contact our support team (https://spideroak.com/help/) about this and they’ll help you sort this out.

      You’re right about the backports, I was just mentioning the general recommendation, each distro from that point on can do whatever they prefer. In case of debian based distros, it’s backports, but other systems behave differently.

      • OK. I will do that. In the meantime, is it possible to get the 5.1.3 rpm for Fedora somewhere? I don’t seem to have the old version on that machine and urgently need to enable it to receive changes from my laptop rather than just uploading them. (Especially since I sync an svn repo between the two machines and need to keep the commits going both ways to avoid too much ugliness.)