www.iaik.tugraz.at
Betriebssysteme KU Security
IAIK
Graz University of Technology
www.iaik.tugraz.at
1. Drivers
2. Security - The simple stuff
3. Code injection attacks
4. Side-channel attacks
www.iaik.tugraz.at
1. Drivers
2. Security - The simple stuff
3. Code injection attacks
4. Side-channel attacks
www.iaik.tugraz.at
Driver Basics
Hardware has a defined interface → reference manual
x86: I/O address space via outb,inb,...
ARM: Memory mapped in physical address space
Let’s have a look at qemu’s mtree command
www.iaik.tugraz.at
Mouse driver (x86)
Send init sequence using inb and outb
Service Mouse IRQs (depending on config)
www.iaik.tugraz.at
MMC driver (ARM)
Send init sequence using memory mapped registers Commands: Read/Write
Send and retrieve data
www.iaik.tugraz.at
Sounds simple?
Writing device drivers is about implementing an interface
Reference manual → what the hardware does
Reference manual → what the hardware expects the OS to do
Large drivers (GPU) can get very complex
www.iaik.tugraz.at
1. Drivers
2. Security - The simple stuff
3. Code injection attacks
4. Side-channel attacks
www.iaik.tugraz.at
Multi user environments
Usermanagement File access rights
→ Extend the existing file system
www.iaik.tugraz.at
DOS attacks
Denial of service → using an unfairly amount of resources to block the whole system
Improve the Scheduler (priorities) Scheduler for I/O activity?
Out of memory handling?
ulimit as an operating system service
www.iaik.tugraz.at
DOS attacks
Denial of service → using an unfairly amount of resources to block the whole system
Improve the Scheduler (priorities) Scheduler for I/O activity?
Out of memory handling?
ulimit as an operating system service
www.iaik.tugraz.at
DOS attacks
Denial of service → using an unfairly amount of resources to block the whole system
Improve the Scheduler (priorities) Scheduler for I/O activity?
Out of memory handling?
ulimit as an operating system service
www.iaik.tugraz.at
Private exec
Modern browsers have a “private browsing” mode Shouldn’t that be a service of the operating system?
priv_exec → execute a program in a sandbox
→ No accesses to real file system, ...
→ No interaction with any hardware
→ Maybe a limited set of syscalls?
www.iaik.tugraz.at
Private exec
Modern browsers have a “private browsing” mode Shouldn’t that be a service of the operating system?
priv_exec → execute a program in a sandbox
→ No accesses to real file system, ...
→ No interaction with any hardware
→ Maybe a limited set of syscalls?
www.iaik.tugraz.at
1. Drivers
2. Security - The simple stuff
3. Code injection attacks
4. Side-channel attacks
www.iaik.tugraz.at
Code injection attack
Idea: Use buffer overflow to inject binary code
int f() {
char b[128];
gets(b);
}
How does the stack look now?
www.iaik.tugraz.at
Code injection attack
Stack:
0xfc return address
0xf8 ebp from calling function
0xf4 b[124],b[125],b[126],b[127]
... ...
www.iaik.tugraz.at
Code injection attack
→ Input string has 128 bytes + attack payload:
"\0\1\2\3" // the ebp i choose
"\xe0\x05\x00\x08" // 080005e0 - execv
"\4\5\6\7" // argument: char* path
"\8\9\10\11" // argument: char** argv
www.iaik.tugraz.at
Countermeasures against code injection
NX-bit in page table → prevent execution on a page Use this bit for stack pages:
PageFault if eip points on a stack page
Think of the attack we just saw: did we execute code on the stack?
→ Return-to-libc/Return-Oriented-Programming (ROP) still possible! Any ideas?
Randomize the position of (shared) library code!
www.iaik.tugraz.at
Countermeasures against code injection
NX-bit in page table → prevent execution on a page Use this bit for stack pages:
PageFault if eip points on a stack page Think of the attack we just saw:
did we execute code on the stack?
→ Return-to-libc/Return-Oriented-Programming (ROP) still possible! Any ideas?
Randomize the position of (shared) library code!
www.iaik.tugraz.at
Countermeasures against code injection
NX-bit in page table → prevent execution on a page Use this bit for stack pages:
PageFault if eip points on a stack page Think of the attack we just saw:
did we execute code on the stack?
→ Return-to-libc/Return-Oriented-Programming (ROP) still possible! Any ideas?
Randomize the position of (shared) library code!
www.iaik.tugraz.at
Countermeasures against code injection
NX-bit in page table → prevent execution on a page Use this bit for stack pages:
PageFault if eip points on a stack page Think of the attack we just saw:
did we execute code on the stack?
→ Return-to-libc/Return-Oriented-Programming (ROP) still possible! Any ideas?
Randomize the position of (shared) library code!
www.iaik.tugraz.at
Countermeasures against code injection
Stack canaries → detect stack corruption Kernel stops execution if stack is corrupted
→ check during context switch
Who protects the kernel against code injection
attacks?
www.iaik.tugraz.at
Countermeasures against code injection
Stack canaries → detect stack corruption Kernel stops execution if stack is corrupted
→ check during context switch
Who protects the kernel against code injection
attacks?
www.iaik.tugraz.at
Syscall-based countermeasures
If injection only changes arguments passed to __syscall :
Randomize syscall numbers
Randomize syscall argument order Blacklist syscalls
Whitelist syscalls
...
www.iaik.tugraz.at
NX-Bit
Execution Prevention for stack pages... what more?
Binary might prefer non-writeable code pages and non-executable data pages
Is there any reason to have a page writeable and executable? (apart from self-modifying code)
W⊕X policy → no page writeable and executable at the same time (except if the binary wants
self-modifying code)
www.iaik.tugraz.at
NX-Bit
Execution Prevention for stack pages... what more?
Binary might prefer non-writeable code pages and non-executable data pages
Is there any reason to have a page writeable and executable? (apart from self-modifying code)
W⊕X policy → no page writeable and executable at the same time (except if the binary wants
self-modifying code)
www.iaik.tugraz.at
NX-Bit
Execution Prevention for stack pages... what more?
Binary might prefer non-writeable code pages and non-executable data pages
Is there any reason to have a page writeable and executable? (apart from self-modifying code)
W⊕X policy → no page writeable and executable at the same time (except if the binary wants
self-modifying code)
www.iaik.tugraz.at
NX-Bit
Execution Prevention for stack pages... what more?
Binary might prefer non-writeable code pages and non-executable data pages
Is there any reason to have a page writeable and executable? (apart from self-modifying code)
W⊕X policy → no page writeable and executable at the same time
(except if the binary wants
self-modifying code)
www.iaik.tugraz.at
NX-Bit
Execution Prevention for stack pages... what more?
Binary might prefer non-writeable code pages and non-executable data pages
Is there any reason to have a page writeable and executable? (apart from self-modifying code)
W⊕X policy → no page writeable and executable at the same time (except if the binary wants
self-modifying code)
www.iaik.tugraz.at
Code injection in kernel
What if you can only write a very small amount of data in the kernel?
Where to jump?
We should prevent the kernel from being able to execute userspace code
Now think of Return-to-libc/ROP...
What if we can set ebp/esp to point into userspace?
www.iaik.tugraz.at
Code injection in kernel
What if you can only write a very small amount of data in the kernel?
Where to jump?
We should prevent the kernel from being able to execute userspace code
Now think of Return-to-libc/ROP...
What if we can set ebp/esp to point into userspace?
www.iaik.tugraz.at
Code injection in kernel
What if you can only write a very small amount of data in the kernel?
Where to jump?
We should prevent the kernel from being able to execute userspace code
Now think of Return-to-libc/ROP...
What if we can set ebp/esp to point into userspace?
www.iaik.tugraz.at
Code injection in kernel
Maybe the kernel should not have userspace data mapped?
→ We remove the userspace mapping from kernel Linux did that too, but they are still vulnerable... why?
→ Identity mapping breaks everything!
www.iaik.tugraz.at
Code injection in kernel
Maybe the kernel should not have userspace data mapped?
→ We remove the userspace mapping from kernel Linux did that too, but they are still vulnerable... why?
→ Identity mapping breaks everything!
www.iaik.tugraz.at
Code injection in kernel
Maybe the kernel should not have userspace data mapped?
→ We remove the userspace mapping from kernel Linux did that too, but they are still vulnerable... why?
→ Identity mapping breaks everything!
www.iaik.tugraz.at
1. Drivers
2. Security - The simple stuff
3. Code injection attacks
4. Side-channel attacks
www.iaik.tugraz.at
Cache Attacks
Cache is faster than Memory
That’s the problem.
www.iaik.tugraz.at
Cache Attacks
Cache is faster than Memory
That’s the problem.
www.iaik.tugraz.at
Cache Attacks - Modern Caches
Shared in Memory → Shared in Cache
clflush flushes data from cache
Shared in Cache → I can flush shared data
Shared libraries → different process execute on
physically shared memory
www.iaik.tugraz.at
Cache Attacks - Modern Caches
Shared in Memory → Shared in Cache clflush flushes data from cache
Shared in Cache → I can flush shared data
Shared libraries → different process execute on
physically shared memory
www.iaik.tugraz.at
Cache Attacks - Flush+Reload
After loading a shared library, attack as follows:
1. clflush interesting function code 2. Wait a bit
3. Check whether function was accessed
www.iaik.tugraz.at
Cache Attacks - Flush+Reload
RSA: Square+Multiply depending on secret key bits
→ 96.7% of the key bits after a single decryption
www.iaik.tugraz.at
Cache Attacks - without shared memory?
F+R requires shared memory → disable shared memory?
Prime+Probe works similar and does not require
shared memory
www.iaik.tugraz.at
Cache Attacks - without shared memory?
F+R requires shared memory → disable shared memory?
Prime+Probe works similar and does not require
shared memory
www.iaik.tugraz.at
Cache Attacks
Cache attack only possible by executing attacker’s code
I only start self-compiled programs.
Are we safe now?
Recent paper: The Spy in the Sandbox - Practical
Cache Attacks in Javascript
www.iaik.tugraz.at
Cache Attacks
Cache attack only possible by executing attacker’s code
I only start self-compiled programs.
Are we safe now?
Recent paper: The Spy in the Sandbox - Practical
Cache Attacks in Javascript
www.iaik.tugraz.at
Cache attack countermeasures
OS could flush cache during context switch
Maybe not the whole cache, but only parts of it User programs could tell the OS which parts they want to protect
And what about Hyperthreading? → disable it?
www.iaik.tugraz.at
Cache attack countermeasures
OS could flush cache during context switch Maybe not the whole cache, but only parts of it
User programs could tell the OS which parts they want to protect
And what about Hyperthreading? → disable it?
www.iaik.tugraz.at
Cache attack countermeasures
OS could flush cache during context switch Maybe not the whole cache, but only parts of it User programs could tell the OS which parts they want to protect
And what about Hyperthreading? → disable it?
www.iaik.tugraz.at
Cache attack countermeasures
OS could flush cache during context switch Maybe not the whole cache, but only parts of it User programs could tell the OS which parts they want to protect
And what about Hyperthreading?
→ disable it?
www.iaik.tugraz.at
Cache attack countermeasures
OS could flush cache during context switch Maybe not the whole cache, but only parts of it User programs could tell the OS which parts they want to protect
And what about Hyperthreading? → disable it?
www.iaik.tugraz.at
Copy-on-write attack
Let’s exploit copy-on-write!
...
Ummm..
How?
www.iaik.tugraz.at
Copy-on-write attack
Let’s exploit copy-on-write!
...
Ummm..
How?
www.iaik.tugraz.at
Copy-on-write attack
Let’s exploit copy-on-write!
...
Ummm..
How?
www.iaik.tugraz.at
Copy-on-write attack
Let’s exploit copy-on-write!
...
Ummm..
How?
www.iaik.tugraz.at
Copy-on-write attack
Regular write access vs. copy-on-write write access
Timing difference?
Yes! Enormous timing difference!
We get a true/false information whether our page was
twice in memory!
www.iaik.tugraz.at
Copy-on-write attack
Regular write access vs. copy-on-write write access Timing difference?
Yes! Enormous timing difference!
We get a true/false information whether our page was
twice in memory!
www.iaik.tugraz.at
Copy-on-write attack
Regular write access vs. copy-on-write write access Timing difference?
Yes! Enormous timing difference!
We get a true/false information whether our page was
twice in memory!
www.iaik.tugraz.at
Page Deduplication
Search Memory for identical pages Make them CoW!
Save lot’s of memory → save lot’s of money!
www.iaik.tugraz.at
Page Deduplication
Search Memory for identical pages Make them CoW!
Save lot’s of memory → save lot’s of money!
www.iaik.tugraz.at
Page Deduplication Attack
1. Fill a page with data
2. Wait
3. Measure write access time to the page 4.
5. High time → found it!
www.iaik.tugraz.at
Page Deduplication Attack
1. Fill a page with data 2. Wait
3. Measure write access time to the page 4.
5. High time → found it!
www.iaik.tugraz.at
Page Deduplication Attack
1. Fill a page with data 2. Wait
3. Measure write access time to the page 4.
5. High time → found it!
www.iaik.tugraz.at
Page Deduplication Attack - Countermeasures
1. Disable Page Deduplication?
2. Deduplicate only read-only pages?
3. Attack requires native code execution?
www.iaik.tugraz.at
