NoSuchCon’13 and crashing Windows with two instructions

The first edition of the NoSuchCon security conference held in Paris ended just a few days ago. Before anything else, I would like to thank all of the organizers (proudly listed at nosuchcon.org) for making the event such a blast! Both the location, venue and speaker line-up were amazing, with lots of free beer and wealth of people to chat with. Overall, I am very happy to have shown up there and I will definitely make sure to attend the second edition of the conference.

Other than drinking, discussing 0-days and visiting Paris, I also had the pleasure to give a talk about the usual subject – Windows kernel security. The exact title of my presentation was “Abusing the Windows Kernel: How to Crash an Operating System With Two Instructions“, and touched on the subject of several different exploitation techniques, internal CPU related behavior and security vulnerabilities (all related to the Windows operating system) that I discovered during the course of last several weeks / months.

While the slide deck was made available to the attendees right at the beginning of my talk at nosuchcon.org/talks (great idea!), I’m reposting them here anyway, in case you haven’t had a chance to take a look yet. In fact, a majority of the talks were interesting and highly technical, so be sure to check the available material for all presentations ;-)

Slides: “Abusing the Windows Kernel: How to Crash an Operating System With Two Instructions” (3.3MB, PDF)

KiTrap0e advisory: “Abusing Windows NT #PF Trap Handler to Bugcheck and Leak Information”

I originally planned to address six separate topics, but due to time constraints I decided to skip some of them in favor of the other ones. A brief description of each technique and vulnerability follows below.

• “nt!memcpy (and the like) reverse copying order” – certain implementations of the memcpy, memmove, RtlCopyMemory and RtlMoveMemory found in the kernel and third-party drivers alike handle the “overlapping regions” corner case by reversing the copy process order from the intuitive left-to-right to right-to-left direction. By starting to write at the end of the destination memory region, the functions facilitate successful exploitation of certain buffer overflow vulnerabilities, by allowing a (relative) write-what-where condition to be provoked.
  .
  While the technique works best for a kernel ← user copy on 64-bit platforms, it can also be applied to a number of other scenarios. For more information, please refer to the “Memory Copy Functions in Local Windows Kernel Exploitation” article published last year in the Hack in the Box Magazine, Issue 009. The Proof of Concept source code of a vulnerable device driver and an exploit used during live demonstration can be found at memcpy_ioctl.zip (3.9kB, ZIP). Note that the code has only been confirmed to be suspectible to a stack cookie bypass when built with WDK 7600.16385.1 for Windows 7 (x64 Free Build), although it should generally work for any 64-bit target.
  .
• “nt!memcmp double-fetch” – an interesting behavior found in the Windows 8 32-bit implementation of the nt!memcmp standard function, making it possible to fake matching regions when a user-mode pointer is passed as one of the function’s parameters. Due to lack of time, this was not covered at NSC; however, our SyScan’13 slides and paper explain the problem thoroughly.
  .
• “PAGE_GUARD and kernel code execution flow” – a technique already described in the “Fun facts: Windows kernel and guard pages” and “A story of win32k!cCapString, or unicode strings gone bad.” blog posts.
  .
• “SegSs, LDT_ENTRY.HighWord.Bits.Default_Big and IRETD” – due to how the “Big“ LDT entry flag in the SS: segment descriptor is handled by the IRETD instruction used for cross-privilege-level transfers in Windows, it is possible to have the CPU disclose the upper 16 bits of the current thread’s kernel stack pointer in 32-bit versions of Windows.
  .
  Proof of Concept source code: small_seg.zip (1kB, ZIP).
  .
  Example output:

  Z:\>smallseg.exe
  [+] High word of kernel stack address: 94070000
  
  Z:\>smallseg.exe
  [+] High word of kernel stack address: 94010000
  
  Z:\>smallseg.exe
  [+] High word of kernel stack address: 956b0000

• “Windows 32-bit Trap Handlers” – the lack of proper sanitization of the previous CPL inside several trap handlers used in 32-bit Windows can be leveraged to disclose addresses of several internal ntoskrnl.exe (or equivalent) symbols in the kernel address space, effectively defeating kernel ASLR (not that it matters much for this particular OS).
  .
  Proof of Concept source code: kitrap01.zip (1.3kB, ZIP) and kitrap0e_addr.zip (1.4kB, ZIP).
  .
  Example outputs:

  Z:\>kitrap01.exe
  [+] Kernel image base: 8320c000, size: 413000
  [+] Iteration 3d000 / 413000
  [+] nt!KiFastCallEntry address: 83249790

  Z:\>kitrap0e.exe
  [+] Kernel image base: 8320c000, size: 413000
  [+] Iteration 3d000 / 413000
  [+] Leaked address: 8324984c
  [+] Leaked address: 83249887
  [+] Iteration 41000 / 413000
  [+] Leaked address: 8324d4ed
  [+] Iteration 412000 / 413000

• “Crashing Windows and leaking bits” – the primary focus area of the overall talk. As it turns out, the nt!KiTrap0e #PF trap handler trusts the KTRAP_FRAME.Ebp field to be a valid kernel-mode pointer when processing faults occuring at a specific, magic Eip values. Again, due to lack of proper KTRAP_FRAME.SegCs sanitization, it is possible to craft a frame with controlled Eip and the user-mode Ebp register, allowing a local attacker to crash the system via an invalid memory reference, or otherwise disclose the least significant bit of any byte in the kernel address space.The two instructions capable of crashing all 32-bit Windows NT-family systems as of today are as follows:
  

  xor ebp, ebp

  jmp 0x8327d1b7

  where 0x8327d1b7 is the nt!KiSystemServiceAccessTeb address.

  Proof of Concept source code: kitrap0e_bsod.zip (0.5kB, ZIP), kitrap0e_leak_bits.zip (1.4kB, ZIP) and kitrap0e_addr_space.zip (1.5kB, ZIP). The programs unconditionally crash the operating system, allow disclosing specific bits of the kernel memory and scan the kernel address space layout, respectively.