Skip to content

Commit

Permalink
emphasis
Browse files Browse the repository at this point in the history
  • Loading branch information
gabe-k authored Apr 26, 2024
1 parent 642d94a commit bb20e1e
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion content/24h2-nt-exploit/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -60,7 +60,7 @@ This bug is similar to the previous one in that it is once again double-fetching

`NtQueryInformationThread`, like other `NtQueryInformation`* syscalls, contains a gigantic switch statement for handling different information classes that can be passed in to query information about kernel objects from user mode. This specific bug is in the handling of the `ThreadTebInformation` information class, which allows reading of parts of the thread’s [TEB](https://learn.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-teb). The input for this specific case is a [`THREAD_TEB_INFORMATION`](https://ntdoc.m417z.com/thread_teb_information) structure residing in user mode memory. This struct contains a destination pointer for where to store the TEB data, as well as a size specifying how much data to read from the TEB.

The code for this bug is less straightforward than the previous one. In this bug the user supplied struct is copied entirely into kernel mode, however, when performing a call to `ProbeForWrite`, the struct in user mode memory is dereferenced again to pass the size. For all uses of the user input after the call to `ProbeForWrite` the kernel copy of the structure is used. `ProbeForWrite` contains a little-known quirk: if a size of zero is passed the function will return immediately without checking the passed address. This means that if a kernel address is passed to `ProbeForWrite` with a size of zero, no exception will be raised, thereby essentially bypassing the probe.
The code for this bug is less straightforward than the previous one. In this bug the user supplied struct is copied entirely into kernel mode, however, when performing a call to `ProbeForWrite`, the struct in user mode memory is dereferenced again to pass the size. For all uses of the user input after the call to `ProbeForWrite` the kernel copy of the structure is used. `ProbeForWrite` contains a little-known quirk: if a size of zero is passed the function will return immediately without checking the passed address. **This means that if a kernel address is passed to `ProbeForWrite` with a size of zero, no exception will be raised, thereby essentially bypassing the probe.**

As in the previous case I have provided my pseudo-code representing how the source code may look, alongside with the assembly from the binary, for both the 23H2 binary which does not include the vulnerable as well as the vulnerable code in 24H2.

Expand Down

0 comments on commit bb20e1e

Please sign in to comment.