How to Defeat Windows 8 ASLR in Getting the Address of KPCR

How to Defeat Windows 8 ASLR in Getting the Address of KPCR

How to Defeat Windows 8 ASLR in Getting the Address of KPCR

by cawan (cawan[at]ieee.org)

on 29/10/2012

In Windows XP or earlier version, KPCR is always located at 0xffdff000.
It is very important for kernel shellcode in getting system process token
in order to duplicate it into another eprocess object which has lower
privilege. This action is normally known as token stealing, and it is
very useful for privilege escalation. However, starting from Windows 7,
it has been ASLRed, and so in Windows 8. This has increased the difficulty
in creating kernel shellcode. However, it is not impossible to defeat it.
First of all, let see how it is ASLRed in Windows 8.

kd> !pcr
KPCR for Processor 0 at 81214000:

    Major 1 Minor 1

NtTib.ExceptionList: 8089612c

    NtTib.StackBase: 00000000

   NtTib.StackLimit: 00000000

 NtTib.SubSystemTib: 80879000

      NtTib.Version: 005ab660

  NtTib.UserPointer: 00000001

      NtTib.SelfTib: 00000000

            SelfPcr: 81214000

               Prcb: 81214120

               Irql: 0000001f

                IRR: 00000000

                IDR: 00000000

      InterruptMode: 00000000

                IDT: 8087c400

                GDT: 8087c000

                TSS: 80879000

      CurrentThread: 812230c0

         NextThread: 00000000

         IdleThread: 812230c0

          DpcQueue:

Well, the KPCR is at 0x81214000. This address is valid until next reboot.
Let see which address range of this KPCR located to.

kd> ln 81214000
(81214000)   nt!KiInitialPCR   |  (81218280)   nt!BcpCursor
Exact matches:
    nt!KiInitialPCR = 

It is within nt kernel with internal symbol KiInitialPCR. Of course the
KiInitialPCR will not be existed in the list of Export Table of nt PE
header. So, how to get the address? Method 1, by using the fixed offset
of KPCR to a well-known symbol which is included in the Export Table of
nt PE header, let's say HalDispatchTable.

kd> dd nt!HalDispatchTable l1
811def28  00000004

So, HalDispatchTable is at 0x811def28. Let's check the offset to KPCR.

kd> ? 81214000-811def28
Evaluate expression: 217304 = 000350d8

Well, it is 0x00350d8. So, when we need to exploit a device driver, we
can calculate the address of KPCR in user mode first before creating the
kernel shellcode to be run for privelege escalation. To calculate the
KPCR, use the following steps,

1. Use NtQuerySystemInformation() with SystemInformationClass of
   SystemModuleInformation to get nt kernel base
2. Use LoadLibrary() to load nt kernel image file into user space and
   get its base (nt kernel base in user space)
3. Use GetProcAddress() to get the address of HalDispatchTable in user
   space (HalDispatchTable in user space)
4. (HalDispatchTable in kernel base) = (nt kernel base) + (HalDispatchTable
   in user space) - (nt kernel base in user space)
5. KPCR = (HalDispatchTable in kernel base) + 0x350d8

Well, the 0x350d8 is valid for Windows 8 system. Let's verify by rebooting
the machine.

kd> dd nt!HalDispatchTable l1
81039f28  00000004

The HalDispatchTable is at 0x81039f28. So by adding 0x350d8 to 0x81039f28
it suppose to be KPCR.

kd> ? 81039f28+350d8
Evaluate expression: -2130251776 = 8106f000

The KPCR should be located at 0x8106f000 now. Let's check.

kd> !pcr
KPCR for Processor 0 at 8106f000:
    Major 1 Minor 1
NtTib.ExceptionList: 8051612c
    NtTib.StackBase: 00000000
   NtTib.StackLimit: 00000000
 NtTib.SubSystemTib: 804f9000
      NtTib.Version: 0001604a
  NtTib.UserPointer: 00000001
      NtTib.SelfTib: 00000000

            SelfPcr: 8106f000
               Prcb: 8106f120
               Irql: 0000001f
                IRR: 00000000
                IDR: 00000000
      InterruptMode: 00000000
                IDT: 804fc400
                GDT: 804fc000
                TSS: 804f9000

      CurrentThread: 8107e0c0
         NextThread: 00000000
         IdleThread: 8107e0c0

          DpcQueue:

Bingo! We win. For your info, in Windows 7, it is 0x92c. I believe it
is service pack dependent, so, if you have chance to verify it in
different Windows version, please let me know.

Now, let's go to method 2, to defeat ASLR with FS register. In user
mode, FS:[0] is always pointing to the current thread object; but in
kernel mode, it is always pointing to KPCR. Let's check.

kd> r fs
fs=00000030

In all current windows system FS always be 0x30. It is easy to get the
base address of this FS value in windbg.

kd> dg 30
                                  P Si Gr Pr Lo
Sel    Base     Limit     Type    l ze an es ng Flags
---- -------- -------- ---------- - -- -- -- -- --------
0030 8106f000 00004280 Data RW Ac 0 Bg By P  Nl 00000493

Since we don't reboot the mechine yet, the KPCR is still at 0x8106f000.
The question now is can we do what dg command did manually? The answer
is yes. Let's go for it. First, lets deconstruct the FS value.

15...3|2   |1 0
index |TI  |RPL
0..110|0  |0 0

RPL=0 means kernel mode
TI=0 means using GDT
index=110 means selector index 6 of descriptors

Now, get the GDT address by using windbg. Of course in creating kernel
shellcode, sgdt instruction should be used.

kd> r gdtr
gdtr=804fc000

The GDT is at 0x804fc000. Let's dump its memory.

kd> dd 804fc000
804fc000  00000000 00000000 0000ffff 00cf9b00
804fc010  0000ffff 00cf9300 0000ffff 00cffb00
804fc020  0000ffff 00cff300 900020ab 80008b4f
804fc030  f0004280 81409306 00000fff 0040f300
804fc040  0400ffff 0000f200 00000000 00000000
804fc050  90000068 81008903 90680068 81008903
804fc060  00000000 00000000 00000000 00000000
804fc070  c00003ff 8000924f 00000000 00000000

Each descriptor is 8 bytes, so, descriptor at index 6 is at 0x804fc030

kd> db 804fc030 l8
804fc030  80 42 00 f0 06 93 40 81 

Let's refer the format of descriptor

63...56        |55|54|53|52|51...48        |47|46   |45|44...40  |39...16                   |15...0
Base 31-24 |G |D  |R |U |Limit 19-16 |P  |DPL|S  |TYPE   |Segment Base 23-0|Segment Limit 15-0

R reserved (0)
DPL 0 means kernel, 3 means user
G 1 means 4K granularity (Always set in Linux)
D 1 means default operand size 32bits
U programmer definable
P 1 means present in physical memory
S 0 means system segment, 1 means normal code or data segment.
Type There are many possibilities. Interpreted differently for system and normal descriptors.

So, the base address can be reconstructed as shown below.

LSB  | 80 42 00 f0 06 93 40 81 | MSB
MSB | 81 40 93 06 f0 00 42 80 | LSB

63...56 = 81
39...16 = 06 f0 00

Well, the base address is at 0x8106f000 and it is exactly the KPCR address
that we obtained by using "dg 30" command in windbg. In next paper, I will
discuss about how to build a platform in creating and testing kernel shellcode
in windbg.