In order to make sure that no context switch is happening after we overwrote the function pointer, immediately after overwriting it, we can consume all the CPU time to avoid that the Idle process be present when this pointer is used.
inside a different process, it would lead to a BSoD. So we have to be careful when corrupting it, because if the corrupted function pointer would be invoked at a wrong context, i.e. This pointer is called quite frequently by the operating system.
#0xed windows windows 10#
On Windows 10 this function pointer can usually (not always) be found at the address 0xffffffff'ffd00538 (if kernel debugging is enabled).
However the ideal function pointer to target in our experience is the HAL!HalpApicRequestInterrupt pointer which is located at index 0xf (offset 0x78). The HalpInterruptController table stores several function pointers which could be corrupted. The same applies for remote kernel vulnerabilities which can be turned into the ability to leak kernel memory addresses remotely.
In the case of Low Integrity Level, the technique is only useful if you are able to leak some kernel pointer address by combining it with another info leak vulnerability. Having the kernel base address, we can easily build a ROP chain to bypass SMEP by turning off the 20th bit of the CR4 register and finally jump into our shellcode located in user space. This is because the exploit could just obtain the kernel base address by calling the NtQuerySystemInformation function. The technique of abusing the HalpInterruptController table could easily be used in situations where the exploit was running at Medium Integrity Level. However, nowadays it’s quite uncommon to find a computer without SMEP (Supervisor Mode Execution Prevention) enabled, which makes this option a less useful alternative. Of course assuming that we know where they are located in memory -).Īnother option would be to overwrite the complete 64-bit pointer with a user mode address to jump directly into your shellcode placed in user space. However, the use of an arbitrary 4-byte write should be enough, because we could use it to overwrite the lower part of a 64-bit pointer to redirect the program flow into other kernel modules such as ntoskrnl.exe, win32k.sys, or hal.dll. So in order to corrupt one of the function pointers in a controlled way, we will need a fully controlled write of either 4 or 8 bytes. Assuming that we are targeting the 64-bit versions of Windows, we know that pointer sizes are 8 bytes. The fact that the HalpInterruptController table is located at a known location and is composed of function pointers, makes it an ideal target for kernel bugs which provide you with an arbitrary write primitives. Corrupting the HalpInterruptController Table Recently, Alex Ionescu abused this technique to implement his DMA attack over USB Type-C which he published in his RECon presentation "Getting Physical With USB Type-C" 3 Afterwards, Enrique Nissim and I found a way to abuse the HAL's heap by abusing the Windows Paging System which we presented in our talk "Getting Physical - Extreme abuse of Intel based Paging Systems" 2. The technique of abusing the HalpInterruptController table was first publicly mentioned in the presentation "Bypassing kernel ASLR - Target: Windows 10 (remote bypass)” by Stéfan Le Berre 1. This made the table an ideal target to be abused for local and remote kernel exploits. One interesting thing to note here is that this table was always located at the same kernel address, except in some special cases. All the stored function pointers would point to various functions inside HAL.DLL. Since Windows 8, a table of function pointers called HalpInterruptController (exported by HAL.DLL) was placed in the first or second memory page of the HAL’s heap (0xffd00000 or 0xffd01000 depending on if kernel debugging is enabled or not). On 32-bit versions of Windows it was located at the address 0xffd00000 while on 64-bit versions of Windows it could be found at the address 0xffffffff'ffd00000. For many years, the HAL's heap in Windows has always been located at the same static kernel address.
0 kommentar(er)
