Blog & News

When Meltdown and Spectre were published in 2018, the reaction was immense. News outlets talked about how no computer was secure, and many experts were shocked to learn of the new class of vulnerabilities they introduced. Meltdown and Spectre, the first microarchitectural CPU vulnerabilities, seemed to redefine what was possible in the realm of hardware flaws. They affected, with few exceptions, almost every CPU manufactured between 1995 and 2018. With this guide, you will be able to demonstrate the Meltdown on your own Computer.

Thanks

This blog post would not have been possible without the awesome people at pwn.college .

The idea was originally a Capture-the-Flag challenge for their System Security course and has now been repurposed for this demo. This is also the reason why there is no source code: It is necessary to preserve academic integrity and preventing the students from easily modifying the exploit code to solve a graded challenge.

I would also like to thank Lorenz Hetterich for his valuable insights into the inner workings of Meltdown and Ruiyi Zhang for testing the exploit.

Purpose of this Guide

With the following guide, you will be able to use the Meltdown exploit within a virtual machine on your own Computer. To our knowledge, no such demonstration is otherwise available. So, next time you want to show your friends a revolutionary CPU exploit at a party, follow the simple steps below and enjoy!

If you are interested, below is a brief explanation of Meltdown. If you just want to run the demo, feel free to skip to the guide .

Explanation of Meltdown

Meltdown exploits the fact that permission checks and instructions run in parallel. This means that instructions may get executed before permission checks finish. While the instructions get discarded later, the microarchitectural state still gets affected by the instructions.

Our exploit tries to read from a memory address that belongs to the kernel. This should not work since normal user programs do not have permission to read kernel memory. However, due to parallel processing, the read execution is still executed before the permission check is finished: The memory contents are fetched and can be used to manipulate the microarchitectural state. As soon as the permissions check returns a result, the fetched information is discarded, but the CPU’s microarchitectural state is still affected.

Note: For the exploit to work the kernel memory address needs to be already loaded in the L1 Cache. Otherwise, the read is not fast enough to be executed before the permission check.

Writing to an Array

Before we attempted the Meltdown exploit, we created a large array. We also ensured that none of its contents were cached. Within the speculatively executed instructions, we compute a value based on the secret data then access a single page of the array, like seen below.

char data = *(char*) 0xffffffff81a000e0; //<-- this fails a permission check.
char tmp = array[data * 4096]; //<-- before the check fails, this instruction is still executed 
// The second instruction affects the microarchitectural state of the CPU

While nothing should have happened, vulnerable CPUs within our array will have cached the page at the location data * 4096. It is now the only cached page within the array.

Reading from the Array

By measuring the response times when ‘probing’ the array, we can now determine which pages inside the array are cached. Because the page at the index accessed by the transient instruction is the only one cached, we can reverse the operation to get the data: data = index / 4096, where index is the index of the cached page.

Disclaimer

The above is a partially simplified explanation of the Meltdown exploit. If you are interested, more detailed and extensive explanations are available in the original paper , in this IEEE spectrum article and, of course, from various other sources on the internet.

Running the Demo

Prerequisites:

• Linux Host system
• CPU vulnerable to Meltdown

1. Ensuring Meltdown is present on CPU:

It should affect all Intel CPUs until the 8th generation and some 9th-generation chips. You can check for your specific CPU with:

grep meltdown /proc/cpuinfo

If your CPU is vulnerable, your output should look something like this

2. Install QEMU

On Debian-based Systems like Ubuntu you can Install QEMU with the following command

sudo apt update 
sudo apt install qemu-system-x86 -y

3. Extract the folder

To make the demo as easy as possible, we already wrote the exploit and put it in a tar archive. The qemu launch scripts has been taken from the GitHub repository pwnkernel .

1. Download and extract the demo to a folder. Download Demo
2. Open a terminal and navigate to the folder you extracted to.

tar -xvf meltdown-yourself.tar.gz 
cd meltdown-yourself

4. Launch the exploit

In this demonstration, we will begin by loading some data into kernel memory, e.g. the memory that is owned by the kernel. We should be unable to read this memory unless we have root privileges. Then, as a normal user, we will run a program, which will read and display the data we initially placed in the kernels' memory.

1. Run sudo ./launch.sh to start the virtual machine. The output should look like this:

Note It’s possible to run the Demo without sudo by adding yourself to the kvm group, which is explained in this Blog post

Now, we are ready to run the automated demonstration of Meltdown. We will try to read the flag at 0xffffffffc0002560

2. Run the exploit with

./meltdown_physical 0xffffffffc0002560 34

3. An output like the one in the image below should appear. If something else, like an exception, happens, exit the VM and retry. Ensure you are following all steps in order.

Congratulations! You successfully used the Meltdown vulnerability against yourself! In this demo you were able to read physical memory as an unprivileged user.

Now you can try reading out other information like the Linux kernel banner located at 0xffffffff82200140:

./meltdown_physical 0xffffffff82200140 100

Please note that this exploit only targets printable characters for demonstration purposes.

Let’s take a quick look at why you won’t be able to put this on a USB stick and steal your friends' pa

Why was Meltdown dangerous?

As explained above, Meltdown allows us to arbitrarily read data stored (almost) anywhere in system memory, as long as we can execute any code on the system. This can be used to steal things like passwords, private encryption keys, or other sensitive data. Some proof-of-concepts were created by the research paper’s authors that revealed Meltdown, including a tool to dump the full memory of a vulnerable machine.

We Cheated - Why this isn’t possible in the Wild (anymore)

Kernel Page Table Isolation

Even before Meltdown was publicized, the scientists who discovered it proposed a mitigation known as KAISER. KAISER was later renamed to KPTI and implemented in the Linux kernel once Meltdown became known. All other operating systems implemented similar mitigations. Kernel Page Table Isolation prevents user processes from seeing kernel memory. It was previously assumed that it was safe to map all kernel memory for each user process, because permission checks were used to prevent access. This was exploited by Meltdown, which led to the introduction of KPTI . This prevents Meltdown attacks on all modern operating systems. For the purposes of this demonstration, KPTI was disabled in the VM by starting the Linux kernel with the -nopti flag.

Preload Kernel Memory in L1 Cache

The standard Meltdown only works if the victim address is already in the L1 cache. To make exploit development easier, we have a Kernel Module that lets a user load an arbitrary address into the L1 cache accomplishes.

To exploit it without this kernel module, an attacker has to find a way to load victim addresses into the L1 cache. This may be achieved in multiple ways: For example, if the attacker’s goal is to read the password hash in a victim process, e.g., sudo, the attacker can attempt the Meltdown exploit multiple times until they hit the exact moment during which the password hash is loaded into the L1 cache. Another approach would be to leverage other microarchitectural attacks like Spectre to force a victim address into the L1 cache.

Conclusion

This demo of Meltdown is an excellent starting point into the world of CPU vulnerabilities and exploits. If you found this interesting, I recommend you check out our Blogpost on CacheWarp . Additionally, if you want to learn about other microarchitectural vulnerabilities, check out Wikipedia .

~ Nils Bauknecht, Youheng Lü