iaik / cache_template_attacks Goto Github PK

This repository contains several tools to perform Cache Template Attacks

License: The Unlicense

C++ 23.33% Makefile 3.17% C 66.50% Shell 7.00%

cache_template_attacks's Introduction

Cache Template Attacks

This repository contains several tools to perform Cache Template Attacks.

Cache Template Attacks are a new generic attack technique, allowing to profile and exploit cache-based information leakage of any program automatically, without prior knowledge of specific software versions or even specific system information.

The underlying cache attack used in this repository is Flush+Reload as presented by Yarom and Falkner in "FLUSH+RELOAD: a High Resolution, Low Noise, L3 Cache Side-Channel Attack" (2014).

The "Cache Template Attacks" paper by Gruss, Spreitzer and Mangard was published at USENIX Security 2015.

One note before starting

The programs should work on x86-64 Intel CPUs independent of the operating system (as long as you can compile it). Different OS specific version of the tools are provided in subfolders.

Warning: This code is provided as-is. You are responsible for protecting yourself, your property and data, and others from any risks caused by this code. This code may not detect vulnerabilities of your applications. This code is only for testing purposes. Use it only on test systems which contain no sensitive data.

Getting started: Calibration

Before starting the Cache Template Attack you have to find the cache hit/miss threshold of your system.

Use the calibration tool for this purpose:

cd calibration
make
./calibration 10

This program should print a histogram for cache hits and cache misses. The number specifies the bucket size for the histogram.

Profiling

In this example we perform some steps by hand to illustrate what happens in the background. Therefore, we will first find the address range to attack.

cat /proc/`pidof gedit`/maps | grep libgedit | grep "r-x"
7fe0674cf000-7fe067511000 r-xp 0001d000 103:04 2768721                   /usr/lib/x86_64-linux-gnu/gedit/libgedit-44.so

We do not care about the virtual addresses, but only the size of the address range and the offset in the file (which is 00000000 in this example). This is also the reason why we don't have to think about address space layout randomization.

Note: On Windows you can use the tool vmmap to find the same information.

This line can directly be passed to the profiling tool in the following step. We will create a Cache Template in this step.

During the profiling you need to perform or simulate a huge number of key presses. The profiling tool gives you 2 seconds of time to switch windows, e.g., to an already opened gedit window.

On Linux, run the following lines:

cd profiling
make
./spy 155 100 7fe0674cf000-7fe067511000 r-xp 0001d000 103:04 2768721                   /usr/lib/x86_64-linux-gnu/gedit/libgedit-44.so

Choose a cache line with a nice number of cache hits and pass it to the generic exploitation spy tool:

cd exploitation
make
./spy 155 /usr/lib/x86_64-linux-gnu/gedit/libgedit-44.so 0x22980

Now this tool prints a message exactly when a user presses a key (in gedit). This spy tool can also be used on Windows just like that.

Note: Cache Template Attacks can be fully automated, but this requires the event to be automated as well.

OpenSSL AES T-Table attack

This example requires a self-compiled OpenSSL library to enable it's T-Table-based AES implementation. Place libcrypto.so in the same folder and make sure the program actually uses it as a shared library. Then run

cd profiling_aes_example
make
./spy

The T-Table is easily locatable in the log file as there are only 64 addresses which are frequently accessed, but not always accessed. Subsequently, you can monitor addresses from the profile to derive information about secret keys.

In the exploitation phase the spy tool has to trigger encryptions itself with an unknown key and can then trivially determine the upper 4 bits of each key byte after about 64 encryptions.

Of course, we know that OpenSSL does not use a T-Table-based AES implementation anymore. But you can use this tool to profile any (possibly closed-source) binary to find whether it contains a crypto algorithm which leaks key dependent information through the cache. Just trigger the algorithm execution with fixed keys

That's it, now it's up to you to find out which of your software leaks data and how it could be exploited. I hope it helps you closing these leaks.

cache_template_attacks's People

Contributors

Stargazers

Watchers

cache_template_attacks's Issues

Some questions about the code, thx!

Hi,
In the file: profiling\aes_example\spy.cpp
Why the key[] are all 0x00?
In the code line: “int fd = open("./libcrypto.so", O_RDONLY);”， is the libcrypto.so a special file which must be reloaded? Or can I replace it with other any .so file?
The size of this file must can full reload in the L1 Cache or L2 Cache size?
What is the function of maccess(void *p)?

The problem of flushandreload() function

Is it wrong that timing first then flush in the function flushandreload(). It should be flush first, should it?

How can I use the "xdo.h"

openssl version for AES attack

Hi,
Can you tell me which version of openssl did you use for the attach, as the new releases have a different implementation?

Error in the command for keypresses

Hello,
Sorry to bother if what I'm saying is wrong but the command given in README.md for the keypresses is not working for me. the grep expression inside the ` ` is not working I think. You need the space after the ^ but then it will also get the space.

Here is possible solution to fix it:
$ cat /proc/`ps -A | grep gedit | grep -oE "^ [0-9]+" | sed "s| ||g"`/maps | grep r-x | grep gdk-3

This is probably not the best solution but I'm not really good with grep, just wanted to point out the mistake.

Why there is the need for the mfence before and after rdtsc?

Intel suggests to use a cpuid rdtsc instruction rdtsc cpuid sequence to measure the time.link. Also the test sequence is fence cpuid rdtsc instruction rdtsc cpuid mfence in the software prefetch paper of CCS16. So why here the calibration code use the mfence rdtsc mfence instr mfence rdtsc mfence sequece? I have combine the test process to one specific cpu0 and give it highest priority, Also I have isolated one specific cpu to make sure no other processes can run on it. However, I still get different thresholds after each run. Sometimes 220 cycles and sometimes 130 cycles.

What to do if I meet unstable calibration results?

In order to get the cache hit/miss threshold, I will the calibration tool to measure that. I will get different results from multiple runs(randomly ranging from 145 to 250). And at the same time, the problem remains even if I use taskset to run the calibration on a fixed core which is isolated from kernel(use isolcpus in grub file to isolate a cpu that will not be scheduled by other process). So have you ever met with problem that multiple runs of calibration produce different results?

Not able to get the results similar to the one mentioned in Readme

Hi,
I am trying to generate the template-profiles of each key by running the linux_low_frequency_example, but the results are nowhere near to the ones mentioned in Readme.md.
The log.txt thus generated doesn't have any address which has a sharp distinction in terms of cache hits for key n. While running the example, I tweaked the code to only look for libgdk-3 files.
Can you please tell me what may have gone wrong, or what set of conditions did you use while experimenting?

Thanks

no xdo file

i am unable to find the xdo.h file

Exploitation on Windows Mingw

Hi @dgruss ,

First of all, many thanks for sharing this very useful project.
I successfully managed to do the profiling on windows using Mingw, and my aim is to perform a side channel attack on my windows environment.
My understanding is that, for an attack to be performed, the exploitation phase needs to be triggered. However, I can only see the documentation for the exploitation on a Linux environment:
cd exploitation/generic
make
./spy /usr/lib/x86_64-linux-gnu/libgdk-3.so.0.1200.2 0x85ec0

This does not work on mingw. Can you please suggest commands that can work on Mingw?

Any help is highly appreciated.
Antonio

Is a virtual machine a good test system?

Thank you for providing this code! I was looking for implementation examples for educative purposes. Yet one thing didn't get from reading the papers:

"Use it only on test systems which contain no sensitive data." does it say in the Readme.md.

Can I try this on a virtual machine without any harm to the data on my host system?

Thank you very much in advance!

error about make operation

when cd calibration, and then
make
it comes some error as follow:

error inconsistent operand constraints in an ‘asm’

is there some wrong in the Makefile?

than you!