Windows Kernel Exploitation Tutorial Part 5: NULL Pointer Dereference
Windows Kernel Exploitation Tutorial Part 5: NULL Pointer Dereference
Windows Kernel Exploitation Tutorial Part 5: NULL Pointer Dereference
Overview
First of all, a happy new year.
After the exhaustive last part in this series, to start o this new year, this post will be about a lighter, more
easy to understand vulnerability. A null pointer dereference vulnerability exists when the value of the
pointer is NULL, and is used by the application to point to a valid memory area. Immediately, the problem
is clear, as if we are able to control the NULL page, write to that location, we’d get our execution. You’d be
easily able to guess here that we’d be using the same technique to allocate NULL page, and place our
shellcode there as we did in the last part, so this one would rely heavily on the information from that post.
Analysis
Let’s look at the NullPointerDereference.c le:
The code clearly states that a magic value (0xBAD0B0B0) is being compared to the user value, and if they
are not same, then the NullPointerDereference is being set to NULL. We can see that in the secure version,
there’s a check to see if the NullPointerDereference is set to NULL or not.
A short analysis in IDA shows the same non-paged pool with tag ‘Hack‘, our magic value, and an interesting
o set of 0x4, which is where we’d be writing the pointer to our shellcode.
Exploitation
Let’s start with our skeleton script:
Our magic value doesn’t trigger any exception, as expected. Now let’s try giving something apart from our
magic value.
An exception is raised this time. Fortunately, our machine continues to work ne without any crashes, so
that just saves some time. Thanks to that Try/Except block in the code.
Now, I’d just borrow the code to allocate NULL page from our previous post, and why we are able to do it
is also explained there. The subtle change here would be the o set of 0x4 from the start of the NULL page.
Perfect, our shellcode’s pointer is written to the 0x4 location, and shellcode perfectly resides in that
location.
Now, we can borrow the nal shellcode from previous post, x the recovery in the end of the shellcode,
and just see what happens. Final exploit should look like:
© rootkit 2018