Back to the CORE
- 2. PoC • ACE • Target for ACE • KernelIo • Target for kernelIo • Overflows & techs • KASLR, PoolSpary, Info Leaks • MMU • Conclusions
- 3. ROP - Historical issue - First ROP appear in MSDOS - Widely used as bypass for DEP - Using gadgets - ROP compilers / finders - Depends on prepared stack layout http://www.exploit-monday.com/2011/11/man-vs-rop-overcoming-adversity-one.htmlhttps://www.auscert.org.au/render.html?it=13408
- 4. Solving old problem ROP • offset to code gadgets - relative • Reuse of existing code • Jumps from one gadget to another • Based on gadgets • Depends heavily on stack layout anti-ROP • Randomization of function position • Randomization of instructions (pos) • Symbolic execution at selected points • CFG • X https://ropguard.googlecode.com/svn- history/r2/trunk/doc/ropguard.pdf www.cs.columbia.edu/~vpappas/papers/kbouncer.pdf www.vdalabs.com/tools/ DeMott_BlueHat_Submission.pdfhttp://www.microsoft.com/en-us/download/details.aspx?id=41138
- 5. CFG - Protect virtual calls - In kernel mode not so widely used anyway, unfortunately … - Per process bitmap - Per process registered functions - Fast lookup! - Only approximation of problem - Handle only old known ROP way of thinking - But finally there! Good job!! - Not handle stack hooking / pivoting - Not handle integrity problems - Not handle ROP in general http://blog.trendmicro.com/trendlabs-security-intelligence/exploring-control-flow-guard-in-windows-10/ http://www.powerofcommunity.net/poc2014/mj0011.pdf http://www.alex-ionescu.com/?p=246
- 6. CF Hijack continue! - Do not use ROP for everything! - ROP are old & obsolete - Use functions in smart way! - Check args, checks output, match your goal! - Mix ROP and functions - Misuse functions as your payload! - Use stack hooking if you *really* need ACE on your code - Find similar, but CFG-approved functions! - 一步一步 (step-by-step) http://blogs.msdn.com/b/vcblog/archive/2014/12/08/visual-studio-2015-preview-work-in-progress-security-feature.aspx http://research.microsoft.com/pubs/101332/BGI-SOSP.pdfhttp://research.microsoft.com/pubs/69217/ccs05-cfi.pdf
- 7. TO THE ROOTS OF PROBLEM!
- 8. Integrity guards fast, reliable, no easy targets anymore!
- 9. Integrity guards • No PLAIN function pointers anymore! – Target reduction – More info leaks needed! • Protect integrity per object level – Results in UAF mitigation • Easy implementation – Objective-C manually ( PROTECTED_ASIGN ) – C++ => compiler can hide this logic • Protect only virtual calls • Fast : only few instructions added http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1332.pdf
- 10. Control Flow Stack Separated stack, only CF instructions can write to this stack idea comes to me from this creative guy : https://sk.linkedin.com/pub/ladislav-nevery/26/a87/498
- 11. Control flow stack • Two stacks – args & vars – return pointers • ROP is not applicable anymore • Stack hooking and pivoting are offline as well! • Special register for cf-stack – cpl0 & cpl3, maintained by context switch – No direct write, as (e/r)ip at x86 – Write onto cf-stack only by cf-instructions • call, jmp, jx, ret, privileged switch – Processor solution needed …
- 12. Safe Memory - Code-Pointer Integrity - Kuznetsov at OSDI - Separate memory for ‘sensitive’ pointers - Isolation on instruction level by using segments fs (gs) - Impressive output – performance & results - No need for addition instructions / regs http://www.cs.berkeley.edu/~dawnsong/papers/ osdi14-paper-kuznetsov.pdf https://www.usenix.org/sites/default/files/conference/ protected-files/osdi14_slides_kuznetsov.pdf
- 13. KERNEL IO – SMEP / SMAP
- 14. windows memory layout On linux caches, on windows pools http://www.alex-ionescu.com/?p=231 http://www.alex-ionescu.com/?p=246
- 15. Cool objects everywhere • Kernel objects in plain state – function pointers – object pointers (buffers, other objs) – object members (size,count,refcount..) • In modules RW states – plain – freelists – ‘vtables’ – locks • Target pool & find your object – nt!_eprocess (->VadRoot) – win32k!tagWND – page tables (cr3) – ...
- 16. OVERFLOWS protections • SMAP • SMEP • KASLR • Pool hardening response • Your data is in kernel already! • Turn your bug to boosted kernel io • ExAllocatePool or Pagetables • You pwn pool object - be relative! • Try - big allocs ... POC : http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/Pwn2Own-2015-Day-One-results/ba-p/6722204 details soon!
- 17. Kernel Pool - About BIG allocs : - Deterministic - especial windows - Linux SLUB +1 - User controllable - alloc - free - data control! - FULL == epic! - Predictable : - Pointers {base + align} - size - properties - Layout-able! - Targeted overflow TBD : http://confidence.org.pl/en/agenda/lecture/when-something-overflowing/
- 18. X64 vs overflows! • Fact : Overflows are (relatively) easy to exploit even on x64 – Although it should be mitigated on secure oriented architecture (/OS) by design • virt addr space > phys addr space – gaps => page_noaccess • Randomized bases of pools • Hunting for buffer overflows : – boost pageheap – Use virt-phys gap more! – Use page guards more! – Randomize more! https://msdn.microsoft.com/en-us/library/windows/hardware/ff549561%28v=vs.85%29.aspx
- 19. reserve, randomize, guard! Overflow results in trap, no stable UAF, sometimes wasting address space can secure it whole! – see cfg ..
- 20. Hunting pool overflows try { • Over/under flow to another object • Try to use UAF • Performance • Waste of space • Small allocs ex(p/c)ect } • Results in trap – page_noaccess • Reused pool but object at different address • Page tables & Vad – coalescing :/ – classic pageheap problems • X64 finally, use it! • Target only big allocs, and (+inner)arrays (compile time)
- 21. KASLR & MMU
- 22. KASLR – user calling! • _sidt / _sgdt – Instruction :/ – basically leaks &ntoskrnl (use kernelio) • user32!gSharedInfo – Bad joke of security – Leaks session pool – leaks nt!_eprocess pointers! (use kernelio) http://www.mista.nu/research/mandt-win32k-slides.pdf
- 23. KASLR – user calling! • SESSION_POOL - Problem bro ? • X64 large address space • but leaks session pool • On session pool mighty objects! win32k!_bitmap • arbitrary write to boost size, or other property • Pool layout & align *NO PROBLEM* • PWN DONE!
- 24. KASLR – timer is calling! Guess where is pool for nt!_ethread
- 25. Timing attacks - Doable - Simple - Ping kernel by time - Spray kernel pool - Ping kernel again - Measure difference - Got kernel pool base! - MMU mechanism was build: - To be fast not ‘too secure’! - TSX is to be disabled by microcode update - But other research & approaches well known! http://labs.bromium.com/2014/10/27/tsx-improves-timing-attacks-against-kaslr/ http://felinemenace.org/~nem o/docs/TR-HGI-2013-001.pdf
- 26. MMU continue! concept, multiple layers of PXN in real http://www.cs.ucla.edu/classes/spring14/cs111/scribe/14b/
- 27. Basic idea 1. Per page privilages 2. Supervisor vs User priv 3. Make mmap / VirtualAlloc 4. memcpy data 5. Flag you page as Supervisor 6. Trigger ACE or Data access 7. Bypass SMEP 8. Bypass SMAP http://viralpatel.net/taj/tutorial/paging.php
- 28. POC – by MWR labs 1.choose address with isolated page tables 1.To be sure write-where does not hit other used memory 2.0x100804020001 1.far enough in memory 2.Kinda magic address, explain later 3.mmap 0x100804020001 4.memcpy 5.Patch S/U bits (write-where) 6.S/U bits need to patch per PXE ! 7.pwn https://labs.mwrinfosecurity.com/blog/2014/08/15/windows-8-kernel-memory-protections-bypass/
- 29. MMU logic • Unmapped memory cause PageFault • Bad access cause PageFault • PageFault handler do lookups • VAD / vm_area • On behalf of lookup will continue • Create / Read Page Tables
- 30. VAD / VM_AREA malloc is lazy Reserve memory in memory struct (AVL tree) Do not create Page Table entries! PTE are created on first access in PageFault handler! NULLPTR deref killed by checking here http://www.codemachine.com/article_protopte.html
- 31. MMU PWNED! 1. write-where 2. nt!_eprocess->VadRoot (task_struct->mm) 3. Substitue with own simple member 4. Fake member covers whole memory range 5. Trigger PageFault (f.e. nullptr deref ;) 6. PageFault handler find it in Vad / mm 7. MMU will create page tables 8. FirstPrototypePte is physical address, you choose! 9. Leads to read / write arbitrary memory! 10.nullptr revival!
- 32. Virtual address == SYMBOLIC Not checked if it is *really* cpl0 or cpl3 page!
- 33. KERNEL - FAIL – SAFE – CHECKS copy_to/from_user ProbeForRead/Write The ProbeForRead routine checks that a user-mode buffer actually resides in the user portion of the address space, and is correctly aligned.
- 34. Think deeper! Make user mode alias translated to target, and then use rw to kernel mode target!
- 35. Self - REF • write-where to patch • but where to write ? • x64 => 4lvl of PXE • PML4, PDP, PT, PTE • c3 holds the PML4 base • others PXE are need to be readed! • … unless self referencing comes in place! • bonus cr3 : physical addresses not so well randomized ;)
- 36. !pte 0x100804020001 How magic is it, self-ref tricking…
- 37. Exploring Potential in every PXE is physical addresses! We point to PM4, after last translation Byte Offset points to PHYSICAL address to be read / write / exec Virtual addresses are just symbolic links to physical ones RWE to all physical memory Equivalent to broke KASLR, SMEP, SMAP, W^X, NonPagePoolNx Windows playing with MMU pagetables, self-ref at INFILTRATE by Alex! http://infiltratecon.com/speakers.html#alex
- 38. Page fault on write
- 39. Confused state => COW
- 40. Framework 1. Provide page dir addr 2. Provide write-where vuln 1. will be used once in current state of OS 2. more generic, write more times 3. Use as KernelIo 4. Snapshot for arm
- 41. Conclusions • Kernel was build meant to be faster than secure • Security is (/can be) boosted by hardware features, incredibly! • Compiler can secure a lot, especially for C++ • Patching to add security != security based model • Redesigning from scratch is not undoable, and maybe not bad idea .. • But I do not expect many core changes, or changes at all, so facts remains : – Changes are hard & slow process – Attack surface is large
- 42. • We are hiring! Kernel & app sec A *LOT* of research mobile, pc M$, android, OSX .. Thank You! Q & A @K33nTeam @zer0mem peter (at) keencloudtech.com
Editor's Notes
- #43: To view this presentation, first, turn up your volume and second, launch the self-running slide show.