Now, we know that we can trigger a NULL pointer dereference, and we also know that the following call is responsible for invoking a callback function:. A quick review of the type associated with the NullPointerDereference variable reveals that the Callback property can be found at offset 0x8 on x64 based systems:.
Therefore, our exploit will allocate memory at the NULL page, and set a pointer to our shellcode we will just use a cc Int-3 breakpoint shellcode for now at address 8h as follows:. To interact with the driver and trigger the exploit, we will use a similar set of calls as our previous post:.
Awesome, we control the rip address. However, remember that our previous shell was developed for Windows 10, whereas now we are exploiting Windows 7. This means that we will need to tweak some of the offsets of the shellcode to match this earlier version.
Later versions of Windows have introduced a security protection which prevents user processes from mapping the NULL page, as we did in the above example. There are however a number of caveats to note when exploiting this vulnerability in the wild:.
Now, if we run a bit application, such as debug. Instead, our injection harness can be found below, with a writeup available for those interested on a previous blog post here. Now we need to craft a DLL which will host our exploit code. First, our kernel shellcode. It is important to note a few subtle differences between this bit Ring-0 shellcode and our previous x64 Windows 7 shellcode:. Next we need to write our DLL. Before we trigger this however, we need to ensure that our shellcode is in place.
There were instances where I diverged from any strategies I saw employed in the blogposts out of necessity or me trying to do my own thing to learn more. The reason for this is simple, the other blog posts do a much better job detailing this information than I could ever hope to.
It feels silly writing this blog series in the first place knowing that there are far superior posts out there; I will not make it even more silly by shoddily explaining these things at a high-level in poorer fashion than those aforementioned posts.
Those authors have way more experience than I do and far superior knowledge, I will let them do the explaining. Also, big thanks to ihack4falafel for helping me figure out why I was having issues in my last blog post with the 2 byte overwrite of my shellcode buffer. I found a much more reliable way of allocating the buffers in Python this time around and everything worked as planned. This was a completely new bug class to me, and it was a ton of fun walking through the vulnerability in IDA.
TriggerNullPointerDereference and see if we hit it. Next we push 8 and then push edi. So it looks like our PoolType is 0. Finally found some constant values for this parameter and it looks like this constant is NonPagedPool. You can read about paged vs. Our next argument is NumberOfBytes which we said was 8. A null-pointer dereference takes place when a pointer with a value of NULL is used as though it pointed to a valid memory area. Null-pointer dereferences, while common, can generally be found and corrected in a simple way.
They will always result in the crash of the process, unless exception handling on some platforms is invoked, and even then, little can be done to salvage the process.
0コメント