This document discusses vulnerability design patterns for kernel exploitation. It outlines several common vulnerability classes for the kernel including out of boundary errors, buffer overflows, and null pointer writes. It provides examples of how these vulnerabilities could be used to achieve kernel code execution or privilege escalation. It also notes how kernel exploitation techniques have evolved over time to bypass defenses like KASLR and discusses developing exploitation tools instead of just shellcode.

1. Vulnerability design
PATTERNS
case: Kernel mode

2. PAST

3. Environment for exploitation
Simple
ioctl
W^X NX KASLR
Hardened
Pool
SMEP SMAP

4. Why kernel exploitation
Full control of
system
Simple
exploitation
Simple bugs

5. KERNEL ESCAPE
few lines of code, simple, effective – for that time
Modified sample from : https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/local/sock_sendpage.rb

6. EVOLUTION

7. Exploitation hierarchy
User
Elevated user
(admin / root)
supervisor

8. Past exploitation shortcut
User
Elevated user
(admin / root)
supervisor

9. Present (+-) & Future : Step by step
User
Elevated user
(admin / root)
Supervisor
• DEP, ASLR, SEHOP, ProtectedFree, Isolated Heap, CFG,
Virtual Table Guards, EMET...
• sandbox, SELinux and alikes
• KASLR, SMEP, SMAP, ..

10. Why kernel escape
• Going to be more and more difficult, but ...
• still .. sometimes easier .. shortcut
• Natural bypass of SELinux
• Full control (cpl0 > cpl3)
• for now do not considering cpl-1, ...

11. exploitation ==> developing
• In past was very easy elevate privileges
• Now everything is fast moving
• You need to adapt to all changes & diversity
• Things are getting more complex
• Your exploitation code is expanding dramatically
• Every change can broke your black-box
• + Process of exploitation need more than ioctl
• Race conditions, complex mechanism break (ttf), sandbox
escapes ...

12. VULNERABILITY DESIGN PATTERNS
kernel case

13. selected vulnerability classes
• Out Of Boundary
• Basic types Over/Under flows
• Stack overflows
• Buffer overflows
• nullptr writes
• Race conditions –not generic, but ...
• may create other bug from above group

14. Out Of Boundary
Simple, mighty, generic

15. OOB
• Read
• Write
• SMAP – limitation, but not
eliminate oob
• GENERIC approach

16. Basic type Over/Under-flow
Generic, simple and useful when it comes to aligned rw

17. Stack Overflow
sometimes protected, sometimes not .. local vars ?
.. depends on compilation ..

18. Stack overview
• Local vars
• canaries
• Protect ret & args
• ... sometimes ... missing
• UNprotected inner calls ?
• Arg in main func preserved in register
• Inner call invoked, register may be putted onto stack
• Rewrite arg (or directly ret) on stack in inner call
• Return to main func with altered arg (in register)
• Can help more than it seems ;)
• Controlled copy, overwrite save your day

19. Buffer Overflow
Common case, can be also byproduct, heap hardening can be
problem

20. Buffer overview
• Windows kernel pool, SLUB
• not so predictable anymore
• but still far from not-predictable at some level
• kmalloc
• targeted kmalloc from user mode ?
• not so hard as can seems
• help with predictability
• Pool spray
• thread, process, pipe, socket ...
• caches (linux)
• can be problem for precise pool layout, but can be solved

21. nullptr pwn
spray, write, pwn .. 64b bit more effort ...

22. user part of cake
Pool
spray
kmalloc
Pipes
ThreadsLocks
ret2dir
Kernel IO

23. kernel pool
pipes, threads .. kmalloc .. spray

24. Kernel IO
If doable, then almighty ...

25. workers, locks, helpers
a lot of common issues per vuln task

26. CODING STYLE MATTERS

27. Elevation of Privilages
USER
• Find nt!_eprocess /
thread_info
• Patch credentials
• Bypass ACL policy
• Reverse engineer per policy
• Implement
• Keep up to date
• Good if not change
frequently .. Not that case 
KERNEL
• Elevate process
• Grant access important
operations (callbacks)
• File access
• Process access
• Registry access
• Network
• How effective without
framework ?

28. Kernel part of cake
• Boosting privs
• Why patching ?
• Recognize and grant access instead
• No LKM ? Are you sure ?
• Kernel exploitation may be equals to enable LKM

29. CC-shellcoding framework
• developing instead of shellcoding ?
• C++, boost, std ?
• Loading your own kernel modules ?
https://github.com/k33nteam/cc-shellcoding
more info : http://www.k33nteam.org/blog.htm -
CC-SHELLCODING
@KEENTEAM

30. 2014 - $500,000
2015 - $??????? Pick a device, name your own challenge!

31. We are hiring!
 Kernel & app sec
 A LOT of research
 mobile, pc
 M$, android, OSX ..
Thank You! Q & A
@K33nTeam