SlideShare a Scribd company logo

Windows Kernel Exploitation : This Time Font hunt you down in 4 bytes

•Download as PPTX, PDF•
•
P
Peter Hlavaty

The document discusses exploiting TrueType font (TTF) vulnerabilities to achieve kernel code execution on Windows systems. It begins by describing the discovery of exploitable bugs in a TTF fuzzer. Despite mitigations like KASLR, NX, SMAP, and CFG, the researchers were able to bypass these protections through techniques like controlled overflows, abusing plain kernel structures, and function-driven attacks. They show how to leverage wild overflows, control kernel memory layout, and hijack control flow to achieve arbitrary code execution. The document emphasizes that OS design weaknesses allow bypassing modern defenses through clever bug chaining and memory manipulation.

1 of 50
FROM KERNEL ESCAPE TO SYSTEM CALC This Time Font hunt you down in 4 bytes! @zer0mem@promised_lu
一步一步 TTF  what ?  Pinging TTF  Different  start to play  wild overflow TECHNIQUE  data to kernel  bitmap wants to help!  bit of math instead write-what  ruling of bitmap!  x64, KASLR, NX, SMEP, SMAP, CFG  echo from the past  have we problems, security ?
#whoarewe [ KEEN TEAM ]  We are doing sec research  We like challenges & security  pwn2own 2013 / 2014 / 2015  actively contributing to geek community  working with project zero  cve / techs / blog / tools / codes / conferences  GeekPwn organizer  #shanghai #beijing
Practical Example NoSuchCon : http://www.slideshare.net/PeterHlavaty/ attack-on-the-core SyScan : http://www.slideshare.net/PeterHlavaty/ back-to-the-core http://www.nosuchcon.org/ https://syscan.org/ https://www.syscan360.org/ we were talking before of some issues in kernel … … this time we will show it in practice
TTF, what is that ? TRUE TYPE FORMAT TrueType is an outline font standard developed by Apple and Microsoft in the late 1980s as a competitor to Adobe's Type 1 fonts used in PostScript. It has become the most common format for fonts on both the Mac OS and Microsoft Windows operating systems. The primary strength of TrueType was originally that it offered font developers a high degree of control over precisely how their fonts are displayed, right down to particular pixels, at various font sizes. With widely varying rendering technologies in use today, pixel-level control is no longer certain in a TrueType font. … THIS TOOL (IS) FABULOUS Offers VM, where in certain conditions you can with your controlled VM instructions achieve : ◦ READ ◦ WRITE In certain scenario it offers boosting surrounding structures in the same pool, what can leads to : ◦ READ ◦ WRITE + some other offering in certain conditions
Ok that was .. lazy [ background ] Nice internals in attackers perspective : https://cansecwest.com/slides/2013/Analysis%20of%20a%20Windows%20Kernel%20Vuln.pdf Fuzzing fonts, structure info .. : https://digteam.github.io/assets/tocttou.pdf https://media.blackhat.com/us-13/US-13-Chan-Smashing-The-Font-Scaler-Engine-in-Windows- Kernel-Slides.pdf
Pinging TTF January meeting about pwn2own February decided we will go after our TTF bugs March pwn2own, 2 kernel escapes to system calcs  building novel TTF fuzzer (@promised_lu)  let fuzzer run for 3 weeks  3 *exploitable* bugs discovered at that period  3-4 weeks for 2 kernel escapes by TTF  more bugs discovered waiting for review now
This time bit different TTF from the past  Bug to modify state of virtual machine  Using VM instructions to pwn kernel this TTF  Bug in building state of VM  Sequence of instruction (4b) to trigger bug  No more control from VM :
Shall we play a game ?
#tools & #materials You will need to parse TTF : TTX You will need to understand format to build your own parser / update-er : View it in human quick & understandable way : FarManager / ConEmu & plugins https://pypi.python.org/pypi/FontTools & https://github.com/behdad/fonttools/ http://www.farmanager.com/ https://twitter.com/ConEmuMaximus5 http://www.microsoft.com/typography/otspec/otff.htm
Minimize your problem! 1. As you got crash, problem can be everywhere 2. Build parsing tools (or use existing ones) 3. Kick all part what is not necessary from TTF out 4. Start working on minimalized TTF https://media.blackhat.com/us-13/US-13-Chan-Smashing-The-Font-Scaler-Engine-in-Windows-Kernel-Slides.pdf
gotcha! Wild Overflow  finally we got root cause!  Only XX pages to be overflowing in  need to alter XX pages in kernel pool without crash ?! No interaction from VM is possible anymore
Take it easy ?!
x64  got overflow  Must control data after  x64 introduce a lot of gaps  Spraying as was used before is ineffective  But …  …not in the same pool http://www.alex-ionescu.com/?p=246
Look at your pool Conditional breakpoint command on ExAllocatePool-0x21 on big allocs & results controlled size & at byte level
Big Pools RANDOMIZATION  Not at big pools  Making controlled holes at will  Precise pool layout SPRAYING  still highly effective inside targeted pool  if you know base of pool, you can hardcode  kmalloc & kfree at your will wild overflow is no problem anymore!
By Design #1 [ overflows ] 1. Do pool layout I. spray bitmaps II. create hole for ttf 2. No PAGE_NOACCESS interaction to care about 3. No crash anymore 4. More complicated when randomization in place, but .. doable .. http://www.slideshare.net/PeterHlavaty/overflow-48573748
write (overflow) – what ? ... N O !  follow right path at right moment  control output of math operation - to some extent
going to be complicated ? You need to go trough some math, semi - controlled write-what meet some conditions to write- semi-what control kernel memory *must* to use _gre_bitmap header member!
By Design #2 [ SMAP betrayal ] Controlled data in kernel, bitmap is just an example! Look more, you will find more … https://msdn.microsoft.com
win32k! _GRE_BITMAP Session Pool kmalloc – CreateBitmap kfree – DeleteObject Controlled – {Set/Get}BitmapBits Known-PLAIN-state header!
By Design #3 [ plain state, ptr ?! ] *PLAIN* header &buffer size&lock feature 1 : user data : kernel data == 1:1 ◦ by design #2 feature 2 : *plain* headers [ in general ] ◦ Properties : size, width, height, … ◦ Pointer to buffers ◦ Pointer to function or ‘vtable’ ◦ Pointer to another member struct : lock, … Consequences : ◦ From user mode I know content of header (size, ..) ◦ I can guess content of header (pointers – base, gran) ◦ I can manipulate it if I have tool to do it [our case] ◦ I can use it when it is necessary [our case] http://www.slideshare.net/PeterHlavaty/attack-on-the-core
Stage #1 [ overflow ]  What we do :  Math-calc based overflow  In right conditions is something somehow rewritten  We can rewrite size  But then we also rewrite Lock  What we get :  size is bigger (but still small!)  Lock - DWORD part is corrupted!
Stage #2 [ full kernel IO ] * Sometimes getting more tricky due to more complicated overflow in our case we need 3 bitmaps idea is similar ...  What we do :  spray, &Lock ptr points to accessible memory  SetBitmapBits to boost followed bitmap size to ~0  What we get* :  FULL KERNEL IO  {Set/Get}BitmapBits at the second bitmap
wrap up Wild overflow semi-control overflowing bytes Kernel memory (part of it) control Bug under control Full kernel IO achieved
what now ? Era of security features ? X64, KASLR, NX, SMAP, SMEP, CFI ?!
Kernel security … X64 – virtual address space KASLR – modules NX – ExAllocatePool nonexec by default SMEP – no easy exec anymore +- SMAP – hopefully SOON CFI – by control flow guard implementation, hopefully SOON http://www.slideshare.net/PeterHlavaty/guardians-ofyourcode
KASLR  Randomization of module addresses  Randomization of pool addresses  When you do not know where your target is then is hard to attack
By Design #4 [ full kernel IO ] Touching invalid memory ? [ x64 VAS > PAS ] Kernel memory layout ? [ KASLR ] Leak pointer chain to valid module : ◦ Info-leak bug ◦ _sidt / _sgdt Turn your bug to pool overflow ◦ misuse object on the pool * Or use old know technique *
Echo from the past [ wtf ?! ]  _sidt & _sgdt from wow64 does not leak  I was lazy to invent new method for second TTF  Wait, hmm, there was something years ago ..  I was sure it is fixed already, but worth to check  Leaking Session Pool objects, problem bro ? https://media.blackhat.com/bh-us-11/Mandt/BH_US_11_Mandt_win32k_Slides.pdf gSharedInfo
Echo from the past [ implementation ]
Are we done ? > Yeah, poping system calcs … but we want kernel EXEC!
Design (#3) strikes back [ plain ptr ] some good function pointers at windows kernel are free to overwrite! ◦ we skip some good candidates like HalDispatchTable to pinpoint some different …
SMEP  X86_CR4_SMEP  Execute user mode code with kernel mode privileges results in BSOD  Previously heavily used as exploitation shortcut
‘SMAP’  X86_CR4_SMAP  In syscall user pass arguments as well  Those arguments have to be readed  No unified method for read / write those inputs is problem for enabling SMAP
NonExec  Code is special case of data  If creating data with EXEC  any data shipped from user mode to kernel can be executed  Unless NonPagedPoolNx take place at ExAllocatePool
SMAP -> SMEP ?  { ‘by design #2’ + ‘echo’ / overflow } bypass SMAP  Page Tables to bypass NonExec & SMEP ?  Lets say some additional protection  HyperVisor solution – EPT, TrustZone , … Page Table attack VadPwn & PageTablePwn boost https://labs.mwrinfosecurity.com/blog/2014/08/15/ windows-8-kernel-memory-protections-bypass/ http://www.slideshare.net/PeterHlavaty/back-to-the-core Insection: AWEsome ... http://www.alex-ionescu.com/?cat=2 - intro
ExAllocatePool We need to get RWE memory OK, lets allocate it! * remember we have kernel IO !! Flags problem, it must be RWE memory ! Address problem, how to leak it back to user ?
Window tricking [ that’s a cheat! ] There we go, some magic function again Working with window handles writeable ‘vtable’ ‘Unused’ function pointers there Returning output back to user Lets mess little bit with logic! provide window pointer as ExAllocatePool flags ? Ensure that window pointer can act as writable & executable flag ;) WINDOW handle (user argument) WINDOW pointer (kernel argument) output returned to user
that must be nasty … http://www.slideshare.net/PeterHlavaty/vulnerability-desing-patterns
Control Flow Guard  Indirect calls check  in kernel mode not so widely used yet, hopefully will be … soon …  bitmap & registered functions
Control Flow Guard [ FDA ]  It covers old way of thinking  Good for mitigating ROP to some extent  CFG-bitmap does not care about integrity of objects  Function-Driven-Attack prone  FDA is more complicated than ROP but nice way  You will searching for vfgadgets instead of rop-gadgets  realize that for now we used function driven attack only (exallocatepool + window tricking) ! http://syssec.rub.de/media/emma/veroeffentlichungen/2015/04/13/COOP-Oakland15_1.pdf http://www.slideshare.net/PeterHlavaty/back-to-the-core
By Design #4 [ CF stack please ] http://www.slideshare.net/PeterHlavaty/back-to-the-core  We have just one stack  Data & Control Flow mixed  any RW instruction can touch stack … what CFI we are talking about ? …
Stack hooking Get address of stack of your kernel thread Use write-where- what primitive (kernel IO) to it Just now, you did stack hooking of you own stack CFI bypassed by design! kernelIO.Write(own_stack, own_driver_ep)
Windows Kernel Exploitation : This Time Font hunt you down in 4 bytes
poping calcs #2 – d’art
btw. Did you spot something ? 1bit-flip to kernel pwn ?
Any problem here ? [ aftermath ] pwn2own – recon => XX - days we found it in 3weeks – for *security* and fun Other guys spending much more time at TTF, most likely not for fun nor for security After we got bug under control, we spent 1-2days with executing it Additional few days with design - d’art  Exploitation technique ? Nope, it is package of design features.. OS design is bit old ? Known security issues persist *PUBLIC* for 4+ years https://securelist.com/files/2015/06/The_Mystery_of_Duqu_2_0_a_sophisticated_cyberespionage_actor_returns.pdf - as a recent example ?
10.24.2015 Pick a device, name your own challenge!
INTERNS WANTED! WE ARE HIRING! :) @K33nTeam hr (at) keencloudtech.com Q & A

More Related Content

Windows Kernel Exploitation : This Time Font hunt you down in 4 bytes

  • 1. FROM KERNEL ESCAPE TO SYSTEM CALC This Time Font hunt you down in 4 bytes! @zer0mem@promised_lu
  • 2. 一步一步 TTF  what ?  Pinging TTF  Different  start to play  wild overflow TECHNIQUE  data to kernel  bitmap wants to help!  bit of math instead write-what  ruling of bitmap!  x64, KASLR, NX, SMEP, SMAP, CFG  echo from the past  have we problems, security ?
  • 3. #whoarewe [ KEEN TEAM ]  We are doing sec research  We like challenges & security  pwn2own 2013 / 2014 / 2015  actively contributing to geek community  working with project zero  cve / techs / blog / tools / codes / conferences  GeekPwn organizer  #shanghai #beijing
  • 4. Practical Example NoSuchCon : http://www.slideshare.net/PeterHlavaty/ attack-on-the-core SyScan : http://www.slideshare.net/PeterHlavaty/ back-to-the-core http://www.nosuchcon.org/ https://syscan.org/ https://www.syscan360.org/ we were talking before of some issues in kernel … … this time we will show it in practice
  • 5. TTF, what is that ? TRUE TYPE FORMAT TrueType is an outline font standard developed by Apple and Microsoft in the late 1980s as a competitor to Adobe's Type 1 fonts used in PostScript. It has become the most common format for fonts on both the Mac OS and Microsoft Windows operating systems. The primary strength of TrueType was originally that it offered font developers a high degree of control over precisely how their fonts are displayed, right down to particular pixels, at various font sizes. With widely varying rendering technologies in use today, pixel-level control is no longer certain in a TrueType font. … THIS TOOL (IS) FABULOUS Offers VM, where in certain conditions you can with your controlled VM instructions achieve : ◦ READ ◦ WRITE In certain scenario it offers boosting surrounding structures in the same pool, what can leads to : ◦ READ ◦ WRITE + some other offering in certain conditions
  • 6. Ok that was .. lazy [ background ] Nice internals in attackers perspective : https://cansecwest.com/slides/2013/Analysis%20of%20a%20Windows%20Kernel%20Vuln.pdf Fuzzing fonts, structure info .. : https://digteam.github.io/assets/tocttou.pdf https://media.blackhat.com/us-13/US-13-Chan-Smashing-The-Font-Scaler-Engine-in-Windows- Kernel-Slides.pdf
  • 7. Pinging TTF January meeting about pwn2own February decided we will go after our TTF bugs March pwn2own, 2 kernel escapes to system calcs  building novel TTF fuzzer (@promised_lu)  let fuzzer run for 3 weeks  3 *exploitable* bugs discovered at that period  3-4 weeks for 2 kernel escapes by TTF  more bugs discovered waiting for review now
  • 8. This time bit different TTF from the past  Bug to modify state of virtual machine  Using VM instructions to pwn kernel this TTF  Bug in building state of VM  Sequence of instruction (4b) to trigger bug  No more control from VM :
  • 9. Shall we play a game ?
  • 10. #tools & #materials You will need to parse TTF : TTX You will need to understand format to build your own parser / update-er : View it in human quick & understandable way : FarManager / ConEmu & plugins https://pypi.python.org/pypi/FontTools & https://github.com/behdad/fonttools/ http://www.farmanager.com/ https://twitter.com/ConEmuMaximus5 http://www.microsoft.com/typography/otspec/otff.htm
  • 11. Minimize your problem! 1. As you got crash, problem can be everywhere 2. Build parsing tools (or use existing ones) 3. Kick all part what is not necessary from TTF out 4. Start working on minimalized TTF https://media.blackhat.com/us-13/US-13-Chan-Smashing-The-Font-Scaler-Engine-in-Windows-Kernel-Slides.pdf
  • 12. gotcha! Wild Overflow  finally we got root cause!  Only XX pages to be overflowing in  need to alter XX pages in kernel pool without crash ?! No interaction from VM is possible anymore
  • 14. x64  got overflow  Must control data after  x64 introduce a lot of gaps  Spraying as was used before is ineffective  But …  …not in the same pool http://www.alex-ionescu.com/?p=246
  • 15. Look at your pool Conditional breakpoint command on ExAllocatePool-0x21 on big allocs & results controlled size & at byte level
  • 16. Big Pools RANDOMIZATION  Not at big pools  Making controlled holes at will  Precise pool layout SPRAYING  still highly effective inside targeted pool  if you know base of pool, you can hardcode  kmalloc & kfree at your will wild overflow is no problem anymore!
  • 17. By Design #1 [ overflows ] 1. Do pool layout I. spray bitmaps II. create hole for ttf 2. No PAGE_NOACCESS interaction to care about 3. No crash anymore 4. More complicated when randomization in place, but .. doable .. http://www.slideshare.net/PeterHlavaty/overflow-48573748
  • 18. write (overflow) – what ? ... N O !  follow right path at right moment  control output of math operation - to some extent
  • 19. going to be complicated ? You need to go trough some math, semi - controlled write-what meet some conditions to write- semi-what control kernel memory *must* to use _gre_bitmap header member!
  • 20. By Design #2 [ SMAP betrayal ] Controlled data in kernel, bitmap is just an example! Look more, you will find more … https://msdn.microsoft.com
  • 21. win32k! _GRE_BITMAP Session Pool kmalloc – CreateBitmap kfree – DeleteObject Controlled – {Set/Get}BitmapBits Known-PLAIN-state header!
  • 22. By Design #3 [ plain state, ptr ?! ] *PLAIN* header &buffer size&lock feature 1 : user data : kernel data == 1:1 ◦ by design #2 feature 2 : *plain* headers [ in general ] ◦ Properties : size, width, height, … ◦ Pointer to buffers ◦ Pointer to function or ‘vtable’ ◦ Pointer to another member struct : lock, … Consequences : ◦ From user mode I know content of header (size, ..) ◦ I can guess content of header (pointers – base, gran) ◦ I can manipulate it if I have tool to do it [our case] ◦ I can use it when it is necessary [our case] http://www.slideshare.net/PeterHlavaty/attack-on-the-core
  • 23. Stage #1 [ overflow ]  What we do :  Math-calc based overflow  In right conditions is something somehow rewritten  We can rewrite size  But then we also rewrite Lock  What we get :  size is bigger (but still small!)  Lock - DWORD part is corrupted!
  • 24. Stage #2 [ full kernel IO ] * Sometimes getting more tricky due to more complicated overflow in our case we need 3 bitmaps idea is similar ...  What we do :  spray, &Lock ptr points to accessible memory  SetBitmapBits to boost followed bitmap size to ~0  What we get* :  FULL KERNEL IO  {Set/Get}BitmapBits at the second bitmap
  • 25. wrap up Wild overflow semi-control overflowing bytes Kernel memory (part of it) control Bug under control Full kernel IO achieved
  • 26. what now ? Era of security features ? X64, KASLR, NX, SMAP, SMEP, CFI ?!
  • 27. Kernel security … X64 – virtual address space KASLR – modules NX – ExAllocatePool nonexec by default SMEP – no easy exec anymore +- SMAP – hopefully SOON CFI – by control flow guard implementation, hopefully SOON http://www.slideshare.net/PeterHlavaty/guardians-ofyourcode
  • 28. KASLR  Randomization of module addresses  Randomization of pool addresses  When you do not know where your target is then is hard to attack
  • 29. By Design #4 [ full kernel IO ] Touching invalid memory ? [ x64 VAS > PAS ] Kernel memory layout ? [ KASLR ] Leak pointer chain to valid module : ◦ Info-leak bug ◦ _sidt / _sgdt Turn your bug to pool overflow ◦ misuse object on the pool * Or use old know technique *
  • 30. Echo from the past [ wtf ?! ]  _sidt & _sgdt from wow64 does not leak  I was lazy to invent new method for second TTF  Wait, hmm, there was something years ago ..  I was sure it is fixed already, but worth to check  Leaking Session Pool objects, problem bro ? https://media.blackhat.com/bh-us-11/Mandt/BH_US_11_Mandt_win32k_Slides.pdf gSharedInfo
  • 31. Echo from the past [ implementation ]
  • 32. Are we done ? > Yeah, poping system calcs … but we want kernel EXEC!
  • 33. Design (#3) strikes back [ plain ptr ] some good function pointers at windows kernel are free to overwrite! ◦ we skip some good candidates like HalDispatchTable to pinpoint some different …
  • 34. SMEP  X86_CR4_SMEP  Execute user mode code with kernel mode privileges results in BSOD  Previously heavily used as exploitation shortcut
  • 35. ‘SMAP’  X86_CR4_SMAP  In syscall user pass arguments as well  Those arguments have to be readed  No unified method for read / write those inputs is problem for enabling SMAP
  • 36. NonExec  Code is special case of data  If creating data with EXEC  any data shipped from user mode to kernel can be executed  Unless NonPagedPoolNx take place at ExAllocatePool
  • 37. SMAP -> SMEP ?  { ‘by design #2’ + ‘echo’ / overflow } bypass SMAP  Page Tables to bypass NonExec & SMEP ?  Lets say some additional protection  HyperVisor solution – EPT, TrustZone , … Page Table attack VadPwn & PageTablePwn boost https://labs.mwrinfosecurity.com/blog/2014/08/15/ windows-8-kernel-memory-protections-bypass/ http://www.slideshare.net/PeterHlavaty/back-to-the-core Insection: AWEsome ... http://www.alex-ionescu.com/?cat=2 - intro
  • 38. ExAllocatePool We need to get RWE memory OK, lets allocate it! * remember we have kernel IO !! Flags problem, it must be RWE memory ! Address problem, how to leak it back to user ?
  • 39. Window tricking [ that’s a cheat! ] There we go, some magic function again Working with window handles writeable ‘vtable’ ‘Unused’ function pointers there Returning output back to user Lets mess little bit with logic! provide window pointer as ExAllocatePool flags ? Ensure that window pointer can act as writable & executable flag ;) WINDOW handle (user argument) WINDOW pointer (kernel argument) output returned to user
  • 40. that must be nasty … http://www.slideshare.net/PeterHlavaty/vulnerability-desing-patterns
  • 41. Control Flow Guard  Indirect calls check  in kernel mode not so widely used yet, hopefully will be … soon …  bitmap & registered functions
  • 42. Control Flow Guard [ FDA ]  It covers old way of thinking  Good for mitigating ROP to some extent  CFG-bitmap does not care about integrity of objects  Function-Driven-Attack prone  FDA is more complicated than ROP but nice way  You will searching for vfgadgets instead of rop-gadgets  realize that for now we used function driven attack only (exallocatepool + window tricking) ! http://syssec.rub.de/media/emma/veroeffentlichungen/2015/04/13/COOP-Oakland15_1.pdf http://www.slideshare.net/PeterHlavaty/back-to-the-core
  • 43. By Design #4 [ CF stack please ] http://www.slideshare.net/PeterHlavaty/back-to-the-core  We have just one stack  Data & Control Flow mixed  any RW instruction can touch stack … what CFI we are talking about ? …
  • 44. Stack hooking Get address of stack of your kernel thread Use write-where- what primitive (kernel IO) to it Just now, you did stack hooking of you own stack CFI bypassed by design! kernelIO.Write(own_stack, own_driver_ep)
  • 46. poping calcs #2 – d’art
  • 47. btw. Did you spot something ? 1bit-flip to kernel pwn ?
  • 48. Any problem here ? [ aftermath ] pwn2own – recon => XX - days we found it in 3weeks – for *security* and fun Other guys spending much more time at TTF, most likely not for fun nor for security After we got bug under control, we spent 1-2days with executing it Additional few days with design - d’art  Exploitation technique ? Nope, it is package of design features.. OS design is bit old ? Known security issues persist *PUBLIC* for 4+ years https://securelist.com/files/2015/06/The_Mystery_of_Duqu_2_0_a_sophisticated_cyberespionage_actor_returns.pdf - as a recent example ?
  • 49. 10.24.2015 Pick a device, name your own challenge!
  • 50. INTERNS WANTED! WE ARE HIRING! :) @K33nTeam hr (at) keencloudtech.com Q & A