The Properties of SharedUserData

There are a number of important properties of SharedUserData, some of which make it useful in terms of temporal addresses and others that make it somewhat infeasible depending on the exploit or hardware support. As far as the properties that make it useful go, SharedUserData is located at a static address, 0x7ffe0000, in every version of Windows NT+. Furthermore, SharedUserData is mapped into every process. The reasons for this are that NTDLL, and most likely other 3rd party applications, have been compiled and built with the assumption that SharedUserData is located at a fixed address^7.1. On top of that, SharedUserData is required to have a backward compatible data structure which means that the offsets of all existing attributes will never shift, although new attributes may be, and have been, appended to the end of the data structure. Lastly, there are a few products for Windows that implement some form of ASLR. Unfortunately for these products, SharedUserData cannot be feasibly randomized, or at least the author is not aware of any approaches that wouldn't have severe performance impacts.

On the negative side of the house, and perhaps one of the most limiting factors when it comes to making use of SharedUserData, is that it has a null byte located at byte index one. Depending on the vulnerability, it may or may not be possible to use an attribute within SharedUserData as a return address due to NULL byte restrictions. As of XP SP2 and 2003 Server SP1, SharedUserData is no longer marked as executable and will result in a DEP violation (if enabled) assuming the hardware supports PAE. While this is not very common yet, it is sure to become the norm over the course of time.