eugnis/spectre-attack

Example of using revealed "Spectre" exploit (CVE-2017-5753 and CVE-2017-5715)

spectre-attack's Issues

I did it on FreeBSD（Just a information)

It's easy to build it on even *BSD because it requires only standard C header, Thanks.

I did make & run, then result on FreeBSD 11.1(sakura public cloud and local machin with Core i5-3210M, both are the same results shown as below):

putting 'The Magic Words are Squeamish Ossifrage.' in memory
Reading 40 bytes:
Reading at malicious_x = 0xffffffffffdffc26... Success: 0x54='T' score=2 
Reading at malicious_x = 0xffffffffffdffc27... Success: 0x68='h' score=2 
Reading at malicious_x = 0xffffffffffdffc28... Success: 0x65='e' score=9 (second best: 0x04='?' score=2)
Reading at malicious_x = 0xffffffffffdffc29... Success: 0x20=' ' score=2 
Reading at malicious_x = 0xffffffffffdffc2a... Success: 0x4D='M' score=2 
Reading at malicious_x = 0xffffffffffdffc2b... Success: 0x61='a' score=2 
Reading at malicious_x = 0xffffffffffdffc2c... Success: 0x67='g' score=2 
Reading at malicious_x = 0xffffffffffdffc2d... Success: 0x69='i' score=2 
Reading at malicious_x = 0xffffffffffdffc2e... Success: 0x63='c' score=15 (second best: 0x04='?' score=5)
Reading at malicious_x = 0xffffffffffdffc2f... Success: 0x20=' ' score=2 
Reading at malicious_x = 0xffffffffffdffc30... Success: 0x57='W' score=2 
Reading at malicious_x = 0xffffffffffdffc31... Success: 0x6F='o' score=37 (second best: 0x04='?' score=16)
Reading at malicious_x = 0xffffffffffdffc32... Success: 0x72='r' score=2 
Reading at malicious_x = 0xffffffffffdffc33... Success: 0x64='d' score=2 
Reading at malicious_x = 0xffffffffffdffc34... Success: 0x73='s' score=2 
Reading at malicious_x = 0xffffffffffdffc35... Success: 0x20=' ' score=2 
Reading at malicious_x = 0xffffffffffdffc36... Success: 0x61='a' score=2 
Reading at malicious_x = 0xffffffffffdffc37... Success: 0x72='r' score=2 
Reading at malicious_x = 0xffffffffffdffc38... Success: 0x65='e' score=7 (second best: 0xBD='?' score=1)
Reading at malicious_x = 0xffffffffffdffc39... Success: 0x20=' ' score=2 
Reading at malicious_x = 0xffffffffffdffc3a... Success: 0x53='S' score=9 (second best: 0x04='?' score=2)
Reading at malicious_x = 0xffffffffffdffc3b... Success: 0x71='q' score=2 
Reading at malicious_x = 0xffffffffffdffc3c... Success: 0x75='u' score=2 
Reading at malicious_x = 0xffffffffffdffc3d... Success: 0x65='e' score=2 
Reading at malicious_x = 0xffffffffffdffc3e... Success: 0x61='a' score=2 
Reading at malicious_x = 0xffffffffffdffc3f... Success: 0x6D='m' score=2 
Reading at malicious_x = 0xffffffffffdffc40... Success: 0x69='i' score=35 (second best: 0x00='?' score=15)
Reading at malicious_x = 0xffffffffffdffc41... Success: 0x73='s' score=2 
Reading at malicious_x = 0xffffffffffdffc42... Success: 0x68='h' score=2 
Reading at malicious_x = 0xffffffffffdffc43... Success: 0x20=' ' score=2 
Reading at malicious_x = 0xffffffffffdffc44... Success: 0x4F='O' score=13 (second best: 0x04='?' score=4)
Reading at malicious_x = 0xffffffffffdffc45... Success: 0x73='s' score=2 
Reading at malicious_x = 0xffffffffffdffc46... Success: 0x73='s' score=2 
Reading at malicious_x = 0xffffffffffdffc47... Success: 0x69='i' score=2 
Reading at malicious_x = 0xffffffffffdffc48... Success: 0x66='f' score=2 
Reading at malicious_x = 0xffffffffffdffc49... Success: 0x72='r' score=2 
Reading at malicious_x = 0xffffffffffdffc4a... Success: 0x61='a' score=2 
Reading at malicious_x = 0xffffffffffdffc4b... Success: 0x67='g' score=2 
Reading at malicious_x = 0xffffffffffdffc4c... Success: 0x65='e' score=2 
Reading at malicious_x = 0xffffffffffdffc4d... Success: 0x2E='.' score=2 

hum... It must be insane...

Mitigations?

Would there be any interest in including some potential mitigations for testing and demonstration. I have just written up one that I have not seem mentioned elsewhere and it seems to perform a lot better than the Intel suggestion of lfence. See https://weblll.org/index.php/spectre-bounds-check-data-flow-mitigation/ which has code that works with this demonstration and thank you for writing it.

So this actually works on AMD 5000 series as well?

Those Zen3 chips are vulnerable to this attack as well?

how to compile the code in MacOS?

gcc output

spectre.c:83:21: warning: passing 'int *' to parameter of type 'unsigned int *' converts between pointers to integer types with different sign [-Wpointer-sign]
                        time1 = __rdtscp(&junk); /* READ TIMER */
                                         ^~~~~
/Library/Developer/CommandLineTools/usr/bin/../lib/clang/8.1.0/include/ia32intrin.h:71:24: note: passing argument to parameter '__A' here
__rdtscp(unsigned int *__A) {
                       ^
spectre.c:85:21: warning: passing 'int *' to parameter of type 'unsigned int *' converts between pointers to integer types with different sign [-Wpointer-sign]
                        time2 = __rdtscp(&junk) - time1; /* READ TIMER & COMPUTE ELAPSED TIME */
                                         ^~~~~
/Library/Developer/CommandLineTools/usr/bin/../lib/clang/8.1.0/include/ia32intrin.h:71:24: note: passing argument to parameter '__A' here
__rdtscp(unsigned int *__A) {
                       ^

undefined reference to `__rdtscp'

When I was compiling the file "Source.c" in Red Hat Enterprise release 6.5, always report the error:
undefined reference to `__rdtscp'.

Does not appear to read from another process

So perhaps I am being obtuse here, but this attack code directly receives the starting address and length of the secret string, does it not? It is reading bytes using the side-channel technique, but it is not reading memory belonging to another process.

Why not split the code into victim.c and attack.c ?

Странное поведение

@Eugnis привет.

Хочу спросить вот о чём: протестировал твою программу на сервере под CentOS до установки обновлений - программа выдаёт весь текст "The Magic Words are Squeamish Ossifrage.", что является успешным выполнением и подтверждением уязвимости сервера, как я понимаю. Но после установки обновлений текст проверки тоже срабатывает.

Можешь объяснить почему так?

pause not found on Linux

I am trying to run the program on Linux, but it produces an error:

Reading at malicious_x = 0xffffffffffdff07a... Success: 0x66=’f’ score=37 (second best: 0x05 score=16)
Reading at malicious_x = 0xffffffffffdff07b... Success: 0x72=’r’ score=2 
Reading at malicious_x = 0xffffffffffdff07c... Success: 0x61=’a’ score=2 
Reading at malicious_x = 0xffffffffffdff07d... Success: 0x67=’g’ score=2 
Reading at malicious_x = 0xffffffffffdff07e... Success: 0x65=’e’ score=19 (second best: 0x00 score=5)
Reading at malicious_x = 0xffffffffffdff07f... Success: 0x2E=’.’ score=2 
sh: pause: command not found

Should it be replaced by sleep?

still vulnerabilities?

Hello,

i did this:

grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: Barriers
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline

and run your program an wondered why it is working.

Can you explain this?

Greetinx, Oliver

Default mode does not illustrate a spectre attack sometimes

the if on line 31 succeeds if x is negative. This is a problem if the compiler puts secret at a lower address than array1, which is the case on my Mac (the offset calculation in main will make malicious_x and therefore x negative). In this case, the program doesn't actually demonstrate a spectre attack. The fix would be to check that x is both greater than or equal to zero and less than array1_size. I'm not sure how to do that without causing branching (I guess that using && must cause branching because of short-circuiting and will mess up branch prediction. Would something like "...int test = x < array1_size; test &= x >= 0; if(test) ..." work?).

illegal hardware instruction

Getting error running this in linux on dual core cpu :

Putting 'The Magic Words are Squeamish Ossifrage.' in memory
Reading 40 bytes:
illegal hardware instruction

$ cat /proc/cpuinfo
..
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Pentium(R) Dual  CPU  E2180  @ 2.00GHz
..

inlining failed in call to always_inline

When I compile the source code with the Code::Blocks, I get some errors:
||=== Build: Debug in Spectre_test (compiler: GNU GCC Compiler) ===| xxx\main.c||In function 'readMemoryByte':| xxx\main.c|65|error: 'for' loop initial declarations are only allowed in C99 or C11 mode| xxx\main.c|65|note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code| xxx\main.c||In function 'main':| xxx\main.c|122|error: 'for' loop initial declarations are only allowed in C99 or C11 mode| ||=== Build failed: 2 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|
and then I use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile the code, I get some other errors:
||=== Build: Debug in Spectre_test (compiler: GNU GCC Compiler) ===| xxx\main.c||In function 'readMemoryByte':| C:\Program Files (x86)\CodeBlocks\MinGW\lib\gcc\mingw32\4.9.2\include\emmintrin.h|1459|error: inlining failed in call to always_inline '_mm_clflush': target specific option mismatch| xxx\main.c|58|error: called from here| C:\Program Files (x86)\CodeBlocks\MinGW\lib\gcc\mingw32\4.9.2\include\emmintrin.h|1459|error: inlining failed in call to always_inline '_mm_clflush': target specific option mismatch| xxx\main.c|64|error: called from here| ||=== Build failed: 4 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|

Compiling with GCC: Stack-smashing detected

The proof of concept code triggers GCC's stack protector. Consider adding -fno-stack-protector to the Makefile?

Note: I'm not sure what to make of this. I feel a proof of concept for a security flaw should not require security protections to be disabled in order to work.