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 off 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.

Again, huge thumbs up to @hacksysteam for the driver.


Analysis

Let’s look at the NullPointerDereference.c file:

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 offset of 0x4, which is where we’d be writing the pointer to our shellcode.

Also, we get an IOCTL of 0x22202b for this.


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 fine 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 offset 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 final shellcode from previous post, fix the recovery in the end of the shellcode, and just see what happens. Final exploit should look like:

Leave a Reply

Your email address will not be published. Required fields are marked *