Exploit-DB #42009
Description: Microsoft Windows 7 Kernel - Pool-Based Out-of-Bounds Reads Due to bind() Implementation Bugs in afd.sys / tcpip.sys
Type: dos
Platform: windows
Date: 2017-05-15
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1127

We have identified two related bugs in Windows kernel code responsible for implementing the bind() socket function, specifically in the afd!AfdBind and tcpip!TcpBindEndpoint routines. They both can lead to reading beyond the allocated pool-based buffer memory area, potentially allowing user-mode applications to disclose kernel-mode secrets. They can also be exploited to trigger a blue screen of death and therefore a Denial of Service condition.

The details are explained below.

----------[ Double-fetch in afd!AfdBind ]----------

In the code of the afd!AfdBind function of the up-to-date afd.sys module (handler of the AFD_BIND IOCTL accessible from ring-3) on Windows 7 32-bit, we can find the following assembly code construct:

--- cut ---
  PAGE:00024D71                 push    0EC646641h      ; Tag
  PAGE:00024D76                 push    [ebp+NumberOfBytes] ; NumberOfBytes
  PAGE:00024D79                 push    10h             ; PoolType
  PAGE:00024D7B                 call    ds:__imp__ExAllocatePoolWithQuotaTag@12
  [...]
  PAGE:00024DD2                 lea     edi, [eax+4]
  PAGE:00024DD5                 push    edi             ; void *
  PAGE:00024DD6                 push    [ebp+P]         ; void *
  PAGE:00024DD9                 call    ds:__imp__memmove <------------------- Fetch #1
  PAGE:00024DDF                 add     esp, 0Ch
  PAGE:00024DE2                 movzx   eax, word ptr [edi] <----------------- Fetch #2
  PAGE:00024DE5                 cmp     ax, 22h
  PAGE:00024DE9                 jb      short loc_24E01
  [...]
  PAGE:00024E01
  PAGE:00024E01 loc_24E01:
  PAGE:00024E01                 push    eax
  PAGE:00024E02                 call    _SOCKADDR_SIZE@4 ; SOCKADDR_SIZE(x)
  PAGE:00024E07                 movzx   eax, al
  PAGE:00024E0A                 cmp     [ebp+NumberOfBytes], eax
  PAGE:00024E0D                 jnb     short loc_24E25
--- cut ---

Which translates to the following pseudo-code:

--- cut ---
  LPINPUTSTRUCT lpKernelStruct = ExAllocatePool(NumberOfBytes);
  memmove(lpKernelStruct, lpUserStruct, NumberOfBytes); <-------------------- Fetch #1

  if (NumberOfBytes < SOCKADDR_SIZE(lpUserStruct->dwStructType)) { <--------- Fetch #2
    // Bail out.
  }
--- cut ---

As can be seen, the first WORD of the input structure is fetched twice from a user-mode buffer: once during the memmove() call, and once when directly accessing it to pass its value as an argument to the SOCKADDR_SIZE function. The SOCKADDR_SIZE function is mostly just a wrapper around the constant sockaddr_size[] array, which has the following values:

 * indexes 0x00..0x01: 0x00
 * index         0x02: 0x10
 * indexes 0x03..0x16: 0x00
 * index         0x17: 0x1C
 * indexes 0x16..0x21: 0x00

The double fetch makes it possible for the first WORD of the structure to have different values on each access from kernel-mode (through another thread concurrently flipping its bits). For example, it could have the valid value 2 or 0x17 at the time of the memmove(), but any other value at the time of the direct access. This would lead to comparing the input structure size with 0 (which is the corresponding entry in sockaddr_size[]), effectively nullifying the sanitization. Other code down the execution flow may then assume that the size of the buffer has been correctly verified, and access some fields at predefined offsets, which may be located outside of the allocated buffer, if the user specifies a very small size.

In our case, the confused code is in tcpip!TcpBindEndpoint, which tries to copy an excessive number of bytes from a very small allocation. A crash log excerpt is shown below:

--- cut ---
  DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6)
  N bytes of memory was allocated and more than N bytes are being referenced.
  This cannot be protected by try-except.
  When possible, the guilty driver's name (Unicode string) is printed on
  the bugcheck screen and saved in KiBugCheckDriver.
  Arguments:
  Arg1: 8c5ed000, memory referenced
  Arg2: 00000000, value 0 = read operation, 1 = write operation
  Arg3: 84c703fe, if non-zero, the address which referenced memory.
  Arg4: 00000000, (reserved)

  Debugging Details:
  ------------------

  [...]

  TRAP_FRAME:  96647818 -- (.trap 0xffffffff96647818)
  ErrCode = 00000000
  eax=9512d970 ebx=95051020 ecx=00000003 edx=00000000 esi=8c5ed000 edi=9505104c
  eip=84c703fe esp=9664788c ebp=96647898 iopl=0         nv up ei ng nz ac po cy
  cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010293
  tcpip!TcpBindEndpoint+0x51:
  84c703fe f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
  Resetting default scope

  LAST_CONTROL_TRANSFER:  from 81722dff to 816be9d8

  STACK_TEXT:  
  9664736c 81722dff 00000003 d1dfd5f3 00000065 nt!RtlpBreakWithStatusInstruction
  966473bc 817238fd [PII_REDACTED] 00000004 nt!KiBugCheckDebugBreak+0x1c
  96647780 816d199d 00000050 8c5ed[PII_REDACTED]0 nt!KeBugCheck2+0x68b
  96[PII_REDACTED]3f98 00000000 8c5ed[PII_REDACTED]0 nt!MmAccessFault+0x104
  96647800 84c703fe 00000000 8c5ed[PII_REDACTED]0 nt!KiTrap0E+0xdc
  96647898 84c7039e 951769a0 8c2e3896 9512d970 tcpip!TcpBindEndpoint+0x51
  966478b8 84c72900 951769a0 966479cc 00000000 tcpip!TcpIoControlEndpoint+0x199
  966478cc 816ccbe5 9664795c d1dfdf7b 00000000 tcpip!TcpTlEndpointIoControlEndpointCalloutRoutine+0x8b
  96647934 84c6d89e 84c72[PII_REDACTED]c 00000000 nt!KeExpandKernelStackAndCalloutEx+0x132
  9664796c 8c2e05ed [PII_REDACTED] 966479f8 tcpip!TcpTlEndpointIoControlEndpoint+0x67
  966479a0 8c2e06aa 84c6d837 951769a0 966479cc afd!AfdTLIoControl+0x33
  966479b8 8c2e3afa 8c53eef0 966479cc 9512d970 afd!AfdTLEndpointIoControl+0x1a
  966479f8 8c2e388a 9512d970 8c53eef0 9512d970 afd!AfdTLBind+0x4b
  96647a40 8c2d3eb8 9512d970 8c53eef0 00000000 afd!AfdTLBindSecurity+0x108
  96647aac 8c2e02b