Dobin 0x73_KernelExploitation.pdf
Dobin 0x73_KernelExploitation.pdf
Dobin 0x73_KernelExploitation.pdf
Set of flashcards Details
| Flashcards | 17 |
|---|---|
| Language | English |
| Category | Religion/Ethics |
| Level | University |
| Created / Updated | 25.06.2019 / 04.07.2019 |
| Weblink |
https://card2brain.ch/box/20190625_dobin_0x73kernelexploitation_pdf
|
| Embed |
<iframe src="https://card2brain.ch/box/20190625_dobin_0x73kernelexploitation_pdf/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
|
Why exploit the kernel?
- Userspace is restricted
- Kernel has access to everything
- All processes (root processes)
- All secrets (harddisk password)
- All security machanisms (SELinux, Seccomp-bpf)
- Kernal attack surface is wied open
- Containerization (Docker, LXC)
What kernel modes are there?
Kernel Mose / Supervisor Mode / Unrestricted Mode / System Mode
- Access to all memory
- Access to special CPU registers
User Mode / Non-Privleged Mode / Restricted Mode
How can you get Kernel execution - the dev way?
Linux:
- Write LKM (Linux Kernel Module)
- Load as Root
- Redhat 7 -> when secure boot is active all kernel modules must be signed with a private key.
Windows:
- Reboot in unsafe / development mode
- Or: Sign code with Driver Certificate ($$$ to Microsoft)
- -> No Untrusted (unsigned) Code in Windows Kernel!
What are the difficulties in exploiting the kernel?
Difficulies in Exploiting:
- If exploit crash -> Crash the system
- No simpel system() shellcode
- Spawning new processes is hard
- Travers memory to find prcess handle, set uid=0
- No brute force
- E.g ASLR
Easier Exploiting:
- Information disclosure is easier (local)
- Kernal ASLR (kASLR) is hard to implement
- Attack surface is gigantic (local)
What are some of the use cases of Kernel Exploiting?
Use cases:
- Mobile (Android, iOS) exploiting / jailbreaking (App -> Root)
- Local privilege escalation (www-data Apache, non-localadmin)
- Pwning the cloud (containerization)
- Rootkits (post breach persistence / hiding)
- Backdoors (gain access again on compromiesed host)
- Cheats (PC, Console)
Name some attack surfaces for Kernel Exploits.
Attack surface examples:
- Drivers
- File Systems
- Sockets
- Syscalls
- /proc, /sys
How is kernal memory maped into physical memory?
Virtual / Logical Address -> Real / Physical Address translation
- Via Page-Table
- Stored in register CR3
- Per-process
- But kenel always included
- Virtual / Logical Address
- What the processes see
- What the kernel sees
- Physical Address:
- CPU untranslated
- What the CPU see's on the bus
What is the TLB?
Page Table: Map virtual addresses to physical
TLB: Translation Lookaside Buffer
- Cache in MMU (Memory Management Unit)
What happens in user space and kernel space when a network packet is sent? (slow)
Send a network packet, slow:
- Userspce process create buffer with data (e.g. A HTTP request)
- Syscall to kernel with address of buffer
- Kernel copies userspace buffer to kernel space
- Kernel splits and manages buffer (split into MTU size, add TCP/IP/Ethernet header etc.) to create network packets
- Kernel copies network packets to special address mapped to NIC RAM
- Kernel <<syscall> NIC (network interface card) with buffer address (in ther RAM)
- NIC sends it over the wire (via local RAM)
What happens in userspace and kernelspace when a network packet is sent? (fast)
Send a network packet, fast:
▪Userspace process create buffer with data (e.g. A HTTP request)
▪Syscall to kernel
▪Kernel copies maps userspace buffer to kernel space
▪Kernel splits and manages buffer (split into MTU, add TCP/IP/Ethernet header etc.) to create network packets
▪Kernel «syscalls» NIC (network interface card) with network packet physical address ▪Buffer gets copied to NIC (NIC’s RAM)
▪NIC sends packet at physical address it over the wire (via DMA)
What is the new hardware layout of CPU, RAM, MCH / Nortbridge / Memory Controler, ICH / Soutbrige / NIC?
Where is the Kernal Logical Addresse maped to in physical memory?
What is Logical Addressing, Virtual / Linear Addressing / Physical Addressing?
Logical Addressing:
- Base + Offset
- Linear Address Space
- Address mapps directly to some hardware address, via offset
Virtual / Linear Addressing:
- Addresses are contigous, but not lnear (page table mapping)
Physical Addressing:
- the catual address of the main memory
What techniques can you use to exploit the kernel and what is done once Remote Code Execution is achieved?
Techniques are the same as in userspace:
- Stack based buffer overflow
- Heap based buffer overflow (slab allocator)
- Racing conditions
- NULL/userspace dereference bugs
- Logical bugs
After geting RCE (Remote Code Execution):
- Patch syscall table
- Or find our shell process and set uid to 0
- Disable SELinux
What is the attack surface of a remote kernel exploit?
Attack Surface:
- TCP/IP Stack
- IPSec
- Drivers: Buetooth / Wifi or similar
- Whatever else is in Kernelspace, and reachable via Network / Signals
What mitigations against kernel exploits are there?
- kASLR
- Available, but disabled by default (hibernation problems)
- DEP
- Default
- CONFIG_DEBUG_RODATA
- But some pages are W & X
- Because of X86 (BIOS etc...)
- Therefor, not so useful
- The usual compile time stuff (but in hard)
- Stack canaries (default)
- Fortify source (default)
- Randstruct
- Randomizes order of struct entries (per build)
- SMEP
- Prevents Execution of userpace code in kernalspace (ret2usr)
- Needs CPU support: Ivy Bridge ++
- Enabled by default in modern distribuitions
- Workaround: In-kernel ROP
- cat / proc / cpuinfo | grep smep
- SMAP
- Deny kenal direct Access to userspace memory
- Needs CPU support Broadwell ++
- Enabled by default in modern distributions
What is the consequence of the linux kernel politics?
Important security fixes are maybe not backported to stable kernels.
