Further to our last blog post regarding the Intel vulnerabilities Meltdown and Spectre, we are now in a position to give more guidance. While it is always important that your operating system is patched and secured, this particular matter is so far-reaching that special note is justified to address the fallout this has caused.
This page has an important foreword on caveats, a section on identifying your OS, patching your OS, and a red part between those two specifically stressing the importance of having a viable backup before making these changes. Of course, if you have any questions – a theme throughout – get in touch.
This article is aimed at customers who manage their own services and have a dedicated server or virtual machine.
At this point shared services have already been patched – if you have a Personal Web, or something similar – you do not have to do anything.
For VM/VPS customers running CentOS or Cloud Linux – it is not advised to reboot with the new kernels in place. We are seeing issues with CentOS6 and CentOS7 kernels not booting after a restart. We have documented the issue for Cloud Linux, CentOS has community posting regarding the matter. From what we understand at this time, the Xen based platform is not vulnerable to Meltdown already. We are waiting on a tested, stable patch from the platform vendor.
Not covered by the above caveats – looking for how to proceed? Good. On with the show.
What Operating System do you Have?
As some operating systems are now end-of-life it is important that you check what version of Windows or Linux you are running before attempting to patch your operating system. Finding out
If you are running Windows on your server simply log in via remote desktop as the Administrator and click the Start button or Windows Logo depending on what you have. If you can see a Run option, click it and type winver.exe and press enter. If you only see a search field type winver and then double-click winver.exe from the results. You can also access the version through control panel under the system properties.
If none of these options work, then try visiting http://whatsmyos.com/ in a browser from the server desktop and this should be able to determine the Windows version.
Log in to the server as root through SSH using Putty or similar and type the command uname -a and then press enter. This will give you the current kernel version and should also display the operating system be it Centos, Ubuntu, etc. If this doesn’t work try typing one of the following commands instead:
lsb_release -a cat /etc/*release cat /etc/issue* cat /proc/version
Can I Patch my Operating System?
The vast majority of our customers will be able to proceed and patch their servers however if you are running any of the operating systems listed below then they have reached end-of-life and you will not be able to apply the patches:
> Any version of Windows 2003 or lower. Windows 2008 and later are fine;
> RHEL4 or lower. Often referred to as Redhat;
> CentOS 5 or lower;
> Ubuntu 17.04 Zesty or lower (excluding 14.04 LTS Trusty, 16.04 LTS Xenial);
> Debian 6 or lower;
> Suse 10 or lower.
If you are running any of the operating systems above, unfortunately, you will not be able to patch your system as updates are no longer provided. In some cases upgrades are possible, in other cases migrations will be necessary. For further information, or if you are unsure please do raise a ticket with email@example.com or call 01745 586070 and select support.
If you are running VMWare then there are additional requirements outside the scope of this post and you should in the first instance refer to the VMWare security blog which discusses your options further: https://blogs.vmware.com/security/2018/01/vmsa-2018-0002.html
BEFORE YOU MAKE ANY CHANGES TO YOUR SERVICE – ENSURE THAT YOU HAVE CURRENT, VALID, USEABLE BACKUPS OF THE DATA YOU REQUIRE SHOULD THE OPERATING SYSTEM NOT BOOT.
IT IS ADVISED THAT AT THIS POINT CENTOS6 AND CENTOS7 USERS ON VIRTUAL MACHINES SHOULD NOT UPGRADE.
This line is important as you should always have an up to date backup but we cannot take any responsibility for a broken system running the following commands.
If you are running a supported operating system then the process to patch against the vulnerabilities will involve one of the following processes:
Just access Windows Updates and Check for new updates through the control panel. If there any updates to install then you should proceed to install the updates, there might be a few if you haven’t done this for a while or have automatic updating switched off. You may also want to revisit the updates section in a few days to check if any further updates are available.
Open an SSH session and type yum update and then hit enter. You may see a large number of updates which ideally should all be installed. Once the update is complete you will need to reboot your server after the updates are complete.
Open a SSH session and type
dnf –refresh update kernel
and hit enter. As above, install the updates and then reboot
You will need to add the testing repository ppa:canonical-kernel-team/pti as at the time of writing these are not mainstream releases. More can be found on their response time line here. Having made good with this – then the usual of:
apt-get update apt-get upgrade reboot
Most patches come in two parts – the kernel itself, and the microcode – effectively ‘CPU firmware’. These mitigate against Variant 3 Meltdown, and one of the Spectre Variants. The remaining variant cannot be fixed on existing architecture, however, the threat surface it exposes is very very low. Once the reboot has completed you should now be patched and secure.
If you are struggling on unsure then please DO drop us an email to firstname.lastname@example.org or pick up the phone and call 01745 586 070 and select Support so that we can investigate and advise.
Firday 19th january 2018
We are seeing CentOS 7 on OnApp now able to restart after recent firmware / microcode updates 3.10.0-693.5.2.el7.centos.plus.x86_64. You may wish to press forward with these now with caution, and be ready to roll these back using grub. Cloud Linux at this point should hold off until the next set of updates go live following CentOS updates, rebuilds, and are currently in testing (despite seeing updates available on Thursday 18th to Firmware).