This post was originally published here by UpGuard.
Meltdown/Spectre Overview
Meltdown and Spectre are critical vulnerabilities affecting a large swathe of processors: “effectively every [Intel] processor since 1995 (except Intel Itanium and Intel Atom before 2013),” as meltdownattack.com puts it. ARM and AMD processors are susceptible to portions of Meltdown, though much less at risk than the affected Intel hardware. Exploiting Meltdown allows attackers to access data from other programs, effectively allowing them to steal whatever data they want.
Meltdown is a serious, widespread vulnerability, and collated information for all Linux providers can be found at https://meltdownattack.com/. At a high level, the solution for Meltdown is to wait for and apply kernel updates as they become available from the responsible vendors. Google and Amazon have patched their systems, and patches are now available from Red Hat and other enterprise Linux providers.
Auditing Susceptibility to Meltdown
That technical solution– patching– leads onto the broader process problem of effectively applying and testing for those updates across all potentially affected systems. This is where UpGuard can automate the detection and reporting of susceptibility to Meltdown.
UpGuard provides a central system for testing and auditing configuration state across all systems, including Linux and Unix variants. With UpGuard I can create a few simple tests that will continuously test my Linux packages so I can be sure when patching is complete and for how long I was exposed.
Continuous Kernel Version Monitoring
Patching against Meltdown and Spectre effectively comes down to kernel updates; to track our susceptibility we need a system of record for all our kernel versions. Fortunately, UpGuard’s default scans of Linux systems already gather the operating system under the `os_release_version` configuration item. I also find the same value in the `kernel` package. With this information centralized in UpGuard I can search for affected kernel versions for each of my Linux Distributions and create a logical grouping of all servers below the desired version.
Continuously testing kernel version using policies.
As patches become available, you’ll want to be able to test every system that the patch has been applied. In UpGuard, I can create a simple comparison for the kernel version with a few clicks and assign it to the group of servers with that operating system . Depending on the operating system, the format and values of the desired OS version will vary, but I can test any of them using the UpGuard “version comparison” test type.
This node has not been patched; once I follow the remediation instructions and upgrade to a safe version of the kernel, the test will stop failing.
Monitor Everything
As a proof of concept, I’ve given examples for how I would test for Meltdown on Linux servers. But Linux and Unix are everywhere! Fortunately UpGuard can do the same auditing and testing for your hypervisors, network devices, Macs, and (with a slightly different method) Windows systems. Even better, once this monitoring is in place it becomes trivial to update it next time there is a security advisory that requires the same patching process.
Get the code
UpGuard users can download pre-made policies to check for relevant Linux versions as they become available on our public Github repo. If you are interested in seeing what else UpGuard can do for infrastructure monitoring, join us for a no-obligation demo of UpGuard Core.
Photo:theinquirer.net
