Bleeding Heart

The fallout from heartbleed seems to be manifesting itself in a range of ways.  I’ve been required to set new passwords for a small number of online services, and expect I may encounter others as and when I next access them.

The main contrast seems to be between admins who tell you what’s happening, vs services that just stop working.  Contrast Apache and Google:

Apache: email arrives from the infrastructure folks: all system passwords will have to be reset.  Then a second email: if you haven’t already, you’ll have to set a new password via the “forgot my password” mechanism (which sends you PGP-encrypted email instructions).  All very smooth and maximally secure – unless some glitch has yet to manifest itself.

Google: @employer email address, which is hosted on gmail, just stopped working without explanation.  But this is the weekend, and similar things have happened before at weekends, so I ignore it.  But when it’s still not back on Monday, I try logging in with my web browser.  It allows me that, and insists I set a new password, whereupon normal imap access is also restored.  Hmmm … In the first place, no explanation or warning.  In the second place, if the password had been compromised then anyone who had it could trivially have reset it.  Bottom of the class both for insecurity and for the user experience.

There is also secondary fallout: worried users of products that link OpenSSL asking or wondering what they have to upgrade: for example, here.  For most, the answer is that you just upgrade your OpenSSL installation and then restart any services that link it (or reboot the whole system if you favour the sledgehammer approach).  Exceptions to that will be cases where you have custom builds with statically linked OpenSSL, or multiple OpenSSL installations (as might reasonably be the case on a developer’s machine).  If in doubt, restart your services and check for the OpenSSL version appearing in its startup messages: for example, with Apache HTTPD you’ll see it in the error log at startup.

Posted on April 14, 2014, in apache, google, security. Bookmark the permalink. 2 Comments.

  1. Yes, an attacker could have reset your @employer password – but what would be the point of that? You’d tell your employer, they’d cancel that account and issue a new one. Inconvenient to you, sure, but also completely worthless to the attacker.

    My employer also uses Google mail, and my password hasn’t been reset, so I guess it’s your employer rather than Google who suspended access and forced the reset.

  2. Google don’t have the luxury of assuming users have a working e-mail account, let alone PGP, but they are usually pretty good on these things.

    This wasn’t a Google wide password change, so probably your company admin mandating the password change – probably clicked the terminate existing sessions and mandate password reset button.

    I’m not too scared about the data leakage on this one. Sure processes leaked various random chunks of freed memory, but unless you were slow to patch, the window of opportunity to organize an attack was fairly small (or arbitrarily large if you found it before Google). By the time we finished our patching, and checked suppliers and frequently used websites, they were all either not vulnerable or already patched.

    As always with SSL/TLS issues, the huge hole is that revocation is the poor sibling. Most browsers are not checking for certificate revocation by default, and for some it is not even a configurable option. No point having a secure site, with a nice fresh password, if your mobile phone mail client then hands it over to anyone who got their hands on a stolen key/cert pair and can operate a wireless access point, or otherwise redirect your traffic.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: