John Carver's picture

I'm curious if there is a recommended procedure for dealing with the Heartbleed OpenSSL bug http://heartbleed.com/?

When I first heard of the problem last evening, I immediately took steps to shut off all SSL and SSH access from outside my firewall until I'm sure that my internal servers and clients are protected.  I then turned my attention to my web server which is running turnkey-drupal7-13.0-wheezy-amd64.  I was under the impression that security updates were being applied daily.  

When I checked the history.log, the last automatic updates were applied on April 6th

Start-Date: 2014-04-06  10:13:56
Commandline: /usr/bin/apt-get -o quiet=1 dist-upgrade -q -y -o APT::Get::Show-Upgraded=true -o Dir::Etc::sourcelist=/etc/apt/sources.list.d/security.sources.list -o Dir::Etc::sourceparts=nonexistent -o DPkg::Options::=--force-confdef -o DPkg::Options::=--force-confold
Upgrade: openssh-server:amd64 (6.0p1-4, 6.0p1-4+deb7u1), openssh-client:amd64 (6.0p1-4, 6.0p1-4+deb7u1), ssh:amd64 (6.0p1-4, 6.0p1-4+deb7u1)
End-Date: 2014-04-06  10:14:01

I was surprised to find there were a number of security patches waiting to be installed.  To be fair, they may have been released on the 7th after the daily check was run.  I went ahead and ran apt-get upgrade.

Start-Date: 2014-04-08  03:53:44
Commandline: apt-get upgrade
Upgrade: libc-bin:amd64 (2.13-38, 2.13-38+deb7u1), base-files:amd64 (7.1wheezy2, 7.1wheezy4), apache2-mpm-prefork:amd64 (2.2.22-13, 2.2.22-13+deb7u1), linux-image-3.2.0-4-amd64:amd64 (3.2.51-1, 3.2.54-2), libexpat1:amd64 (2.1.0-1, 2.1.0-1+deb7u1), apache2-utils:amd64 (2.2.22-13, 2.2.22-13+deb7u1), apache2:amd64 (2.2.22-13, 2.2.22-13+deb7u1), apache2.2-common:amd64 (2.2.22-13, 2.2.22-13+deb7u1), apt:amd64 (0.9.7.9, 0.9.7.9+deb7u1), locales:amd64 (2.13-38, 2.13-38+deb7u1), libapache2-mod-rpaf:amd64 (0.6-7, 0.6-7+wheezy1), multiarch-support:amd64 (2.13-38, 2.13-38+deb7u1), libssl-dev:amd64 (1.0.1e-2+deb7u3, 1.0.1e-2+deb7u5), apache2.2-bin:amd64 (2.2.22-13, 2.2.22-13+deb7u1), wget:amd64 (1.13.4-3, 1.13.4-3+deb7u1), libapt-pkg4.12:amd64 (0.9.7.9, 0.9.7.9+deb7u1), libc6-dev:amd64 (2.13-38, 2.13-38+deb7u1), tzdata:amd64 (2013d-0wheezy1, 2013i-0wheezy1), localepurge:amd64 (0.6.3, 0.6.3+deb7u1), openssl:amd64 (1.0.1e-2+deb7u3, 1.0.1e-2+deb7u5), linux-libc-dev:amd64 (3.2.51-1, 3.2.54-2), libc-dev-bin:amd64 (2.13-38, 2.13-38+deb7u1), libc6:amd64 (2.13-38, 2.13-38+deb7u1), libssl1.0.0:amd64 (1.0.1e-2+deb7u3, 1.0.1e-2+deb7u5)
End-Date: 2014-04-08  03:56:03

 

A few packages were updated in addition to the security patches.  This morning when I checked again, I found a new set of packages for openssl.  These appear to address the heartbleed bug and recommend a reboot after installation.

Start-Date: 2014-04-08  15:13:01
Commandline: apt-get upgrade
Upgrade: libssl-dev:amd64 (1.0.1e-2+deb7u5, 1.0.1e-2+deb7u6), openssl:amd64 (1.0.1e-2+deb7u5, 1.0.1e-2+deb7u6), libssl1.0.0:amd64 (1.0.1e-2+deb7u5, 1.0.1e-2+deb7u6)
End-Date: 2014-04-08  15:13:18

 

  1. If I had been patient, would the security updates been applied the next time the script ran? Or is it necessary to manually apply the updates because of the prompts for user input?
  2. If I wanted to apply only security updates, is there a way to do so without having to copy the command line from the log above?
  3. In any case, we need to make sure to reboot our appliances after the updates are applied.
Forum: 
John Carver's picture

To answer my own question #1, another test server automatically applied the upgrade

Start-Date: 2014-04-08  10:35:44
Commandline: /usr/bin/apt-get -o quiet=1 dist-upgrade -q -y -o APT::Get::Show-Upgraded=true -o Dir::Etc::sourcelist=/etc/apt/sources.list.d/security.sources.list -o Dir::Etc::sourceparts=nonexistent -o DPkg::Options::=--force-confdef -o DPkg::Options::=--force-confold
Upgrade: openssl:amd64 (1.0.1e-2+deb7u3, 1.0.1e-2+deb7u5), libssl1.0.0:amd64 (1.0.1e-2+deb7u3, 1.0.1e-2+deb7u5)
End-Date: 2014-04-08  10:35:46

I rebooted just to make sure.  1.0.1e-2+deb7u5 is the patched version of openssl.

Squeeze appliances are apparently not affected by the bug.

Several experts are recommending generating new host keys.  Is there a procedure for this?

Information is free, knowledge is acquired, but wisdom is earned.

Jeremy Davis's picture

Great detective work! There have been some others also asking about this and I created new v12.1 and v13.0 LAMP appliances (on AWS) to test for this bug. With all the security fixes installed (as they do on AWS - and nightly) they were both secure. FWIW the latest version of OpenSSL is actually 1.0.1e-2+deb7u6. You can check with:

apt-get update && apt-get policy openssl

Also the command that is configured to run nightly (to take care of security patches) is

cron-apt

Finally, I can't verify the quality of the info, but the Heartbleed site (you linked to yourself) has a fair bit of info. Also there is a site that tests webservers for the vulnerability which might also be a handy tool.

John Carver's picture

Yeah, I noticed that 1.0.1e-2+deb7u6 was released not long after I posted.  I didn't bother to update the post.

Next step is to regenerate all new keys.  I only use self-signed certs so it's no big deal, but I pity the cert providers.

Information is free, knowledge is acquired, but wisdom is earned.

Add new comment