Go Back   Exetools > General > General Discussion


Thread Tools Display Modes
Old 01-09-2018, 08:34
chants chants is offline
Join Date: Jul 2016
Posts: 645
Rept. Given: 21
Rept. Rcvd 43 Times in 26 Posts
Thanks Given: 593
Thanks Rcvd at 973 Times in 441 Posts
chants Reputation: 43
Meltdown exploit and Spectre

Does anyone have any working code samples which detect the exploit on a given processor or any practically useful instances:
Simply amazing how long these hardware bugs have been around, and that it might be some time until the hardware cleans up the mess and so software workarounds are slowing down the whole system now to deal with the problematic leaky cache timing side-channel.

It is an interesting discovery and quite fascinating sequence of events though for those of us into the low-level processor details:

The Meltdown exploit
Ordinarily, the mechanisms described above are considered secure. They provide the basis for most modern operating systems and processors. Meltdown exploits the way these features interact, to bypass the CPU's fundamental privilege controls and access privileged and sensitive data from the operating system and other processes. To understand Meltdown, we consider the data that is mapped in virtual memory (much of which the process is not supposed to be able to access), and look at how the CPU responds when a process attempts to access unauthorized memory. The process is running on a vulnerable version of Windows or Linux, on a 64 bit processor of a vulnerable type. (This is a very common combination across almost all desktop computers, notebooks, laptops, servers and mobile devices.)

Like every other process and the operating system itself, the rogue process has access to a virtual address space (virtual memory) of billions of gigabytes. Ignoring privilege controls, this space will be used in a way that maximizes efficiency. Most is unallocated – it doesn't have any data whatsoever. Some areas are designated to the rogue process for its own instructions and data. For efficiency, and ignoring privilege controls, this space also contains all the other data being used in all the other processes that are running, including the operating system, and possibly even memory that was used but has not been emptied or addresses that always map directly to the entirety of physical memory. However the fact that all of this data is mapped into each process's memory is ordinarily considered completely safe, because the CPU's privilege controls will prevent its abuse. Any attempt by the rogue process to access any of this other data – and indeed anything except its own authorized memory – will result in an exception (error condition). The request will fail and no data will be provided to the rogue process, preserving security.
If a process were to try reading from unauthorized memory, the read instruction will at first be scheduled and pipelined by the CPU, as with all instructions. As usual, an execution unit will be selected and a memory controller unit will be told to read the contents of memory from the address in the instruction, so that it is ready and quickly available within the CPU, when it's time to execute the rest of the instruction. At some point before the instruction is allowed to produce any output, the privilege check will complete elsewhere. In the case of an unauthorized read, the execution unit will be told that the instruction failed the privilege check. It will discard all data from the instruction, never pass anything to the process, and it will instead abandon that instruction and move to the next one.
In theory, provided the execution unit, memory controller, scheduler and privilege check are fault-free, this is a completely secure approach. Even though the privileged memory was read by the execution unit and memory controller unit initially, the instruction execution was then abandoned midway and the unauthorized part-processed workings were discarded – the outcome was correct. However, as Meltdown shows, it is not as secure as has been believed.
In the early stages of the instruction execution, the CPU's scheduler scheduled two events – a privilege check, and the first steps of executing the instruction. As part of that, while it was waiting for the privilege check to complete, the execution unit started by fetching the data. In the case of the rogue process, the data was from an unauthorized address, but it was still fetched by the memory controller during the initial stage of instruction execution, even if it was then discarded and abandoned when the privilege check completed and failed.
Ordinarily this has no effect and security is enforced, because the read data is never made available in any way, until the privilege check has completed. However even when the instruction fails, the data has already been requested by the execution unit and fetched by the memory controller, in order to be ready to process it, and although the execution unit discards the data upon privilege check failure, the CPU cache was in fact updated as an automatic part of fetching the data from memory, in case the same data might be needed shortly a second time. At this point, Meltdown intervenes:
The CPU cache is not readable by an unauthorized process, because it is internal to the CPU. But by using a cache timing attack (a form of side channel attack), it is possible for a rogue process to determine whether data from a specific address is held within the CPU cache, even if it cannot itself read the actual data from that address. If data from some address has been cached by the CPU then a second instruction to read that address will use the CPU cache for the purpose (fast), if not then the CPU would have to request the data to be read from memory (slower). The rogue process can use this difference in timing to detect which of these took place, and whether the address was already in the CPU cache. Usually this wouldn't be an insurmountable vulnerability on its own, but Meltdown can use it combined with other features of the CPU instruction set to gain full access to all mapped memory...
When an instruction asks for memory to be read, it can specify the address to read from, in many different ways. These include indirect addressing modes – instructions that tell the CPU to read from memory X, use the value stored at X to calculate a second address Y, and the "answer" (or returned value) is the value stored in address Y. Meltdown uses this as part of the basis of a side-channel attack to determine the content of the memory at any given address. Suppose the address at 2000 is not directly readable by the process, but could have any value from 1 to 5, and suppose we ignore privilege checking. One could execute an instruction "Read the value of memory at an address given by (5000 plus the value of memory at address 2000)". If address 2000 contains 1, then the CPU will try to return the value of memory at address 5001; if address 2000 contains 2 it will try to return the value of memory at address 5002, and so on. If we then execute a timing attack, and it shows that the CPU was slower to read from addresses 5001, 5002, 5003 and 5005, but faster for address 5004, then we can conclude that the reason is that it has cached data from address 5004, and that this is because it has recently accessed that address. So we can deduce that address 2000 contained the value "4".
If 2000 is an unauthorized address, then this attempt should fail and the process should learn nothing from it, because of the privilege check.
But the problem – as shown by Meltdown – is that, in order to be efficient, the CPU has already started to prepare itself by accessing the memory locations that may be needed, in parallel with the privilege check. That means, when the privilege check fails and the execution unit (correctly) discards the data and abandons the read instruction, address 2000 has already been read and its contents already used to read address 5004, even if the read was abandoned and the in-progress data was discarded by the CPU's execution unit. Moreover, when the memory controller was told by the execution unit to access address 5004 in preparation for the instruction, it automatically put a copy of that data into the CPU cache as usual, in case of a future request for the same data, and that copy is still present in the CPU cache. (It isn't expected to be detectable without authorization, and will often be needed again quite soon when it's been needed a first time.) So even though the instruction itself failed, and even though the process cannot directly read the contents of address 2000 or the cached content of any of addresses 5001 to 5005, the rogue process can still use its side-channel attack to identify that address 5004 is in the cache and the other addresses between 5001 and 5005 are not, so it can still determine that the address that the instruction would have tried to read is 5004, and therefore that the content of unauthorized address 2000 is "4".
Reply With Quote
Old 01-09-2018, 12:09
TechLord TechLord is offline
Banned User
Join Date: Mar 2005
Location: 10 Steps Ahead of You
Posts: 786
Rept. Given: 389
Rept. Rcvd 247 Times in 112 Posts
Thanks Given: 806
Thanks Rcvd at 2,066 Times in 595 Posts
TechLord Reputation: 200-299 TechLord Reputation: 200-299 TechLord Reputation: 200-299
Originally Posted by chants View Post
Does anyone have any working code samples which detect the exploit on a given processor or any practically useful instances:
Here we go :

Utilities to Check the Status on Windows and Linux :

SpecuCheck - a Windows utility for checking the state of the software mitigations against CVE-2017-5754 (Meltdown) and hardware mitigations against CVE-2017-5715 (Spectre):

Compiled Checker Here :


Microsoft has also produced a PowerShell script that checks whether your
PC is vulnerable.

Use the following steps to install and run the test.

1. Press the Windows key and type PowerShell.
2. Right click the PowerShell shortcut and select Run as Administrator.
3. Type Install-Module SpeculationControl and press Enter.
4. If you are prompted to install the NuGet provider, type Y and press Enter, and repeat
if you are warned about installing from an untrusted repository.
5. With the installation complete, type Import-Module SpeculationControl and press
6. Type Get-SpeculationControlSettings and press Enter.

Spectre & Meltdown vulnerability/mitigation checker for Linux :


Meltdown Exploit PoC :
PoC from Spectre Attacks- Exploiting Speculative Execution :

Last edited by TechLord; 01-09-2018 at 14:06.
Reply With Quote
The Following 3 Users Say Thank You to TechLord For This Useful Post:
an0rma1 (01-09-2018), chants (01-09-2018), Stingered (01-09-2018)
Old 01-09-2018, 13:27
Stingered Stingered is offline
Join Date: Dec 2017
Posts: 208
Rept. Given: 0
Rept. Rcvd 1 Time in 1 Post
Thanks Given: 270
Thanks Rcvd at 145 Times in 70 Posts
Stingered Reputation: 2
Nice Powershell script. Unfortunately, I doubt my 8yr old laptop is going to see a BIOS update any time soon.
Reply With Quote

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Java log4j exploit chants General Discussion 0 12-20-2021 14:29
Exploiting CVE-2018-1038 - Total Meltdown TechLord General Discussion 9 04-27-2018 23:21
NSA Exploit Kit (Decrypted Files) TechLord General Discussion 20 05-03-2017 01:32
Rowhammer Exploit mcp General Discussion 1 03-11-2015 05:52

All times are GMT +8. The time now is 23:33.

Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX, chessgod101
( 1998 - 2022 )