Unless you’ve been living under a rock (or on a remote island, with no Internet connection), you’ve heard about the latest vulnerabilities that impact modern processors.
I’m sure that most of our readers are scrambling in order to assess the risk, patch systems and what not, so we have decided to write a diary that will clear the confusion a bit and point out some important things that people might not be aware of.

What is this all about?

First, if you haven’t already listened to SANS’ webcast about Meltdown and Spectre by Jake Williams, I strongly suggest that you go and do that – the recording is available at https://www.youtube.com/watch?v=8FFSQwrLsfE
Jake explains everything pretty well (although I think with some minor errors about Spectre that I will try to clear below).

In a nut shell, what do these two vulnerabilities allow an attacker to do?
While I won’t go into technical details here (which are pretty complex – this was in my opinion amazing research, although the Google’s blog could have been a bit easier to read :)), here is what it boils down to:

1. Meltdown allows a local, userland (unprivileged) process to read contents of any memory mapped to the process. This includes kernel memory and this is why this vulnerability is dangerous.
2. Spectre allows a local, userland (unprivileged) process to read contents of memory of other processes (this is where maybe Jake’s presentation wasn’t so clear about). Update 2: Spectre does not allow reading of kernel memory. It looks as Spectre can indeed be used to read kernel memory. Additionally, while it's maybe not 100% clear, from Google's blog post (https://googleprojectzero.blogspot.hr/2018/01/reading-privileged-memory-with-side.html) it definitely appears that this is cross-process.

There is a Spectre PoC out, however in the PoC a single process is used: a secret is set in memory as a character array and then its contents are read by exploiting the vulnerability. This made people think that it’s intra-process only (single process), but it is actually cross process memory ready (see the Spectre paper page 2, Attacks using Native Code, available at Spectre Paper).

Ok, now that we know what the vulnerabilities are about we can assess the risk: as you can see, in both cases, an attacker actually needs to run some code on the target machine to exploit these vulnerabilities.
This makes vulnerabilities highest risk for the following:

• Anything that runs untrusted code on your machine (a browser typically),
• Anything running in virtualization or clouds.

So, for a typical company, on your Domain Controller (for example), the risk is actually very, very low: since you are not running untrusted code there (hopefully), an attacker should not be able to exploit these vulnerabilities in the first place.

For a typical user, the browser presents the highest risk, but we have yet to see proof of concept code that exploits this vulnerability through JavaScript – and browser vendors have started issuing patches as well (for example, Mozilla has issued a new version of Firefox, 57.0.4, where they have decreased the precision of time sources to make attacks such as Spectre more difficult or impossible). If you run stuff as Administrator: Spectre makes no difference for you really.

In other words: the world will not end over the weekend.

What to do now?

Keep an eye on the development and patches released by vendors, but not differently than other patches.
On the contrary, pay special attention to impact of patches: there are known cases where AV programs caused BSOD on systems with the patch. This is actually a reason why Microsoft added a check for a registry key that needs to be set by the AV program to indicate that it’s compatible with the patch: if the key is not present, the patch will not be installed!

If you are installing the patch on a Windows server: be aware that besides installing the patch, a registry key needs to be added manually to enable it: https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution
Without this registry key nothing will happen. Microsoft presumably added this because on servers, impact to performance might be higher (so it’s up to you to take the risk … or not). Test, test, test.
The good thing with this approach is that, once you install the patch and enable the mitigations: if your system blows up you can change the registry keys and disable the mitigations. This will allow you to try out the patch. As I said: test, test, test.

Update 1: fellow handler Didier Stevens did some tests of patches on the Windows platform – as you can see on the screenshot below, the patch for the Spectre vulnerability (CVE-2017-5715) requires a firmware (microcode) update as well.
This means that, if there is no firmware update for your platform, that the patch is useless currently.

Update 3: CPU firmware (microcode updates) can certainly be delivered by the OS vendors, and there have been such cases in the past. This makes it much better for the end-users, since a BIOS update will not be required.
However, there is a down side with this approach: such microcode updates are lost when the CPU is reset or powered down. It means that they need to be applied every time the system boots up. Still, it's a viable solution.

Checking the released updates so far, it appears that RedHat, for example, has included certain microcode updates in their patches (although for only several CPU families it seems). Microsoft, on the other hand, has not done so (who knows why, and whether they will do it).

Update 1/8/2018: Some vendors have already released BIOS updates that mitigate the mentioned issues, so check their web pages (I have verified that Lenovo has released BIOS updates, and successfully installed them).

Finally, we have yet to see what other impacts these (huge) changes will have, besides reducing performance. For example, it appears that the patches will impact ability to capture RAM contents, which might further impact various forensics activities.

We are carefully monitoring everything around these vulnerabilities and will, as always, try to be your source of clear and precise information.
If you have something to add, please contact us here – especially if there are errors in the diary (or post a comment).

--
Bojan
@bojanz

INFIGO IS