The looming spectre of a meltdown
For the latest information on how this issue affects Forcepoint security products, please see the technical bulletin: Meltdown and Spectre Vulnerability
2018 has gotten off to a tough start with the news of the Meltdown and Spectre (CVE-2017-5715, CVE-2017-5753, and CVE-2017-5754) vulnerabilities. This is a broad industry problem that affects almost everyone, everywhere. Processors from Intel, AMD, and ARM are all potentially vulnerable to at least one variant of Spectre or Meltdown which can be implemented within Apple, Linux and Windows environments. However, currently we are unaware of active exploits of this in the wild.
Forcepoint is working with our industry partners to examine these issues carefully and analyze the potential impact to our products, customers and resellers. While updates to systems may be required, due to the way our appliances and cloud operate, we can report today that our exposure is limited, as only our own trusted code should be running on these devices. As soon as patches are made available, Forcepoint will rigorously test these in our performance laboratory and will carefully assess the safest and most pragmatic way to proceed for our customers and partners.
It is important to note for someone to make use of the Spectre/Meltdown attacks requires malicious code to be executed on the target system. This is not a trivial point as the attack path is more complex than a simple phishing attack, for example.
Original blog post
After a flurry of rumors and speculation over the Christmas and New Year period, we’ve finally been given sight of two new whitepapers describing the attacks and a blog post from Google Project Zero describing a range of side-channel attacks against recent CPUs.
The attacks (in brief)
Modern CPUs are, unsurprisingly, rather complicated devices: they have the ability to run multiple commands simultaneously and to capitalize on this they can execute some commands out-of-order.
In effect, this means that they can a) choose to execute commands further ahead in a program if something else (e.g. reading data from memory) is delaying the current one; and b) speculate on which branch of a program to follow after a decision point in execution.
Meltdown relies on the first type of out-of-order execution to read important OS memory and Spectre uses the latter ‘speculative execution’ approach.
Who is affected?
Unfortunately, more or less everyone, albeit to differing extents. Processors from Intel, AMD, and Arm are all potentially vulnerable to at least one variant of the Spectre/Meltdown attack, and the attacks can be implemented within both Linux and Windows environments.
Stepping into the realms of speculation (no pun intended) so soon after the publication of a major vulnerability is, as always, fraught with caveats.
On unpatched systems both Spectre and Meltdown attacks can aid code execution attacks by defeating ASLR and leaking important information about memory layout. With Spectre’s applicability to web browser sandboxing, it seems plausible that we will come to see attacks which attempt to use a similar technique to leak browsers’ memory layouts in preparation for the deployment of an arbitrary code execution exploit.
That said, while these vulnerabilities are very severe and widespread to an extent which certainly hasn’t been seen in recent times, the bases on which they were developed aren’t overly new: side-channel attacks pre-date the modern computer and ring0 escalations have been seen before.
Probably the most alarming of the proofs-of-concept released is the use of branch target injection (i.e. Spectre) to read host memory from inside a virtual machine. Again, this isn’t an entirely new concept: VM breakout bugs have naturally been of interest to researchers for quite some time, typically using virtual device drivers to attempt to run code on the host machine (e.g. Venom).
At the time of writing, it remains unclear as to whether or not some variant of Spectre could be used to inject code into the host machine as opposed to reading the contents of its memory – Intel believe this not to be viable – but, regardless, the ability to read host memory is a major security risk on its own and its ubiquity courtesy of being the result of a hardware flaw a major concern. It seems likely that mitigations against this in particular are likely to have a measurable performance impact until non-vulnerable hardware is developed, released, and deployed.
If there’s a silver lining to this (for some, at least) it’s that it appears that access to vulnerable systems or VMs – be that local or remotely via another exploit – is required to implement these attacks against the kernel. While this is scant consolation for suppliers of virtualised infrastructure who may be exposed to malicious actors purchasing cloud-hosted VMs, it does push the actual exploitation of these vulnerabilities into the somewhat more rarefied territory of advanced, persistent threat actors.
Mitigation & recommendations
Patches are being released for major operating systems at the time of writing and, as always, Forcepoint Security Labs strongly recommend adherence to a robust patching policy.
There are, however, some caveats:
- Microsoft have identified that certain antivirus packages make unsupported calls to kernel memory which, after application of the new patch, can cause ‘blue screen’ errors on both client and server devices;
- Microsoft also warn of potential performance impacts after applying the patch, the extent of which is unclear at present. While it seems likely that CPU vendors will already be working hard to mitigate these issues in their next-generation hardware, this will have an ongoing impact until all of the affected hardware is retired – possibly in half a decade or more.
We will provide updates via this blog and appropriate customer communication channels as more information becomes available.