Meltdown and Spectre: clearing up the confusion

Meltdown and Spectre: clearing up the confusion
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: 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. 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 I will be teaching next: Web App Penetration Testing and Ethical Hacking - SANS Amsterdam October 2020	Bojan 392 Posts ISC Handler Jan 8th 2018
Subscribe	Jan 8th 2018 2 years ago
Are you sure Spectre cannot access kernel memory? From Project Zero’s writeup: "A PoC for variant 1 (Spectre) that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory " "A PoC for variant 2(Also Spectre) that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second" Link: https://googleprojectzero.blogspot.jp/2018/01/reading-privileged-memory-with-side.html Apple also claims that Spectre can access Kernel memory. Link: https://support.apple.com/en-us/HT208394 Also in the webcast, it was explained that Meltdown is a local attack only but apparently Mozilla has confirmed it is remotely exploitable through JS from a webpage. “Mozilla has confirmed that both Meltdown and Spectre are remotely exploitable by embedding attack code in mundane JavaScript files delivered via web pages" Link: https://www.bleepingcomputer.com/news/security/mozilla-confirms-web-based-execution-vector-for-meltdown-and-spectre-attacks/	Anonymous
Quote	Jan 6th 2018 2 years ago
Thank you - indeed, I believe you are right and that Spectre can be used to read kernel memory as well (according to the Google's blog post). I have update the diary. Regarding remote vs local attack: these are all, in my opinion, local attacks. A browser is, obviously, the most common attack vector since it allows the attacker to create JavaScript code which will be executed locally (and the browser indeed executes untrusted code all the time). That being said, there are many many other potential attack vectors for this: maybe JavaScript in PDF? Or macros in Office documents. But it all boils down to the attacker being able to execute code locally. Cheers, Bojan	Bojan 392 Posts ISC Handler
Quote	Jan 6th 2018 2 years ago
Didier Stevens' "test" just shows the output of Matt Miller's PowerShell script ... which depends on the Windows update Microsoft published some days ago. The "cpuid" program offered on https://skanthak.homepage.t-online.de/cpuid.html works independent from the Windows updates and shows whether the microcode update is installed.	Anonymous
Quote	Jan 7th 2018 2 years ago

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:

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.
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.

CVE-2017-5715 update

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

I will be teaching next: Web App Penetration Testing and Ethical Hacking - SANS Amsterdam October 2020

Bojan

392 Posts
ISC Handler

Jan 8th 2018

Are you sure Spectre cannot access kernel memory?

From Project Zero’s writeup:
"A PoC for variant 1 (Spectre) that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory "
"A PoC for variant 2(Also Spectre) that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second"

Link: https://googleprojectzero.blogspot.jp/2018/01/reading-privileged-memory-with-side.html

Apple also claims that Spectre can access Kernel memory.
Link: https://support.apple.com/en-us/HT208394

Also in the webcast, it was explained that Meltdown is a local attack only but apparently Mozilla has confirmed it is remotely exploitable through JS from a webpage.

“Mozilla has confirmed that both Meltdown and Spectre are remotely exploitable by embedding attack code in mundane JavaScript files delivered via web pages"
Link: https://www.bleepingcomputer.com/news/security/mozilla-confirms-web-based-execution-vector-for-meltdown-and-spectre-attacks/

Anonymous

Thank you - indeed, I believe you are right and that Spectre can be used to read kernel memory as well (according to the Google's blog post).
I have update the diary.

Regarding remote vs local attack: these are all, in my opinion, local attacks. A browser is, obviously, the most common attack vector since it allows the attacker to create JavaScript code which will be executed locally (and the browser indeed executes untrusted code all the time).
That being said, there are many many other potential attack vectors for this: maybe JavaScript in PDF? Or macros in Office documents. But it all boils down to the attacker being able to execute code locally.

Cheers,

Bojan

Bojan

392 Posts
ISC Handler

Didier Stevens' "test" just shows the output of Matt Miller's PowerShell script ... which depends on the Windows update Microsoft published some days ago.

The "cpuid" program offered on https://skanthak.homepage.t-online.de/cpuid.html works independent from the Windows updates and shows whether the microcode update is installed.

Anonymous