Meltdown and Spectre Updates needed for AWS Instances?

Peter Woodall's picture

Is anyone aware of Linux updates to patch for these vunerabilities?


Jeremy Davis's picture

I hope to write up a blog post about this ASAP, as there are now updates for both Debian Wheezy (basis of TurnKey v13.x) and Debian Jessie (basis of TurnKey v14.x).

Considering the amount of noise in the media around this, we decided to hold off on posting anything until we actually had something to add to the discussion and/or some specific instructions that TurnKey Linux users could follow. As of today, we're now there! I had hoped to post something already, but I've been tied up with support, so it may not be until tomorrow now. In the meantime, I'll try to address your concerns here. Please note that I will probably reuse some of this content for my blog post, but I will aim to provide some more detail when I do that.

For starters, currently only Meltdown is patchable. AFAIK Spectre on the other hand, is still unpatched in all OS (inc Windows, MacOS and Linux). There will be patches coming to mitigate it to some degree, but my reading suggests that as this is primarily a hardware design flaw, the software patches won't completely resolve it. OTOH Spectre is much harder to leverage than Meltdown, so is less of a risk to start with. It would require someone to already have some degree of access to your server to be able to exploit it. There are not currently any known cases of exploits which leverage Meltdown or Spectre "in the wild", although I imagine that is only a matter of time seeing as there is already some Proof of Concept code floating about.

As for AWS, according to their Security announcement:

All instances across the Amazon EC2 fleet are protected from all known instance-to-instance concerns of the CVEs previously listed. Instance-to-instance concerns assume an untrusted neighbor instance could read the memory of another instance or the AWS hypervisor. This issue has been addressed for AWS hypervisors, and no instance can read the memory of another instance, nor can any instance read AWS hypervisor memory. We have not observed meaningful performance impact for the overwhelming majority of EC2 workloads.

Reading between the lines, plus some other reading I've done suggests that they have patched their host kernels and have developed some additional Xen patches (Xen is the hypervisor used by AWS). The updates that they have applied ensure that instances can't leverage these attack vectors to gain unauthorised access to another instance's data. Whilst they do say that all instances are protected (including PV instances) they do suggest that PV instances may still be somewhat vulnerable, so you would be well advised to migrate to an HVM instance if you are still using a PV instance.

As to the applying the patches themselves, unless you have disabled auto security updates, you should have already received the updated kernel. However, to apply it you will need to restart your instance. If you wish to be 100% sure, check that the latest kernel package has been installed (instructions for TurnKey v14.x):

apt-cache policy linux-image-amd64
On TurnKey v14.x should return the following:
  Installed: 3.16+63+deb8u1
  Candidate: 3.16+63+deb8u1
  Version table:
     4.9+80+deb9u2~bpo8+2 0
        100 jessie-backports/main amd64 Packages
 *** 3.16+63+deb8u1 0
        500 jessie/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     3.16+63 0
        500 jessie/main amd64 Packages

Users of TurnKey v13.x, should see something similar, although the patched version is "3.2+46+deb7u1" (instead of "3.16+63+deb8u1").

If your instance does not show the above, then please check that the auto-updates are still enabled and run the following:

apt-get update
apt-get install linux-image-amd64
(if you are using an instance launched from the AWS Marketplace, you will need to prepend those commands with 'sudo').

Then recheck using the above apt-cache command. You should be good now.

To check the kernel version currently running please use this command:

uname -a

On an old system which hasn't been rebooted in ages, I get (bad):

Linux tkldev 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19) x86_64 GNU/Linux
On a v14.2 system which is running the patched kernel, you should see the following (good):
Linux tkldev 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) x86_64 GNU/Linux
As noted above, v13.x systems will show a different kernel version, but where "3.16.51-3+deb8u1" is in the output above, patched Wheezy based machines will instead show "3.2+46+deb7u1". Unfortunately I don't currently have one running, so can't 100% confirm the full details.

Please note that v12.x and earlier WILL NOT get a fix for this issue. Users of v12.x or earlier and STRONGLY advised to migrate to a currently supported version.

If you have further concerns or questions, please post and I'll do my best to answer.

Jeremy Davis's picture

Please have a read of the blog post too/instead. I provide a fair bit more detail there, plus lots of additional links.
Peter Woodall's picture

Your post gave me all the info I needed so all is good with my instances.



Post new comment