Remote Attacks

The ability to apply the techniques described in this document in a remote scenario would obviously increase the severity of the problem. In order to do this, an attacker would need the ability to either infer or be able to calculate some of the key elements that are used in the generation of a cookie. This would rely on being able to determine things like the process creation time, the process and thread identifier, and the system uptime. With these values, it should be possible to predict the state of the cookie with similar degrees of accuracy. Of course, methods of obtaining this information remotely are not obvious.

One point of consideration that should be made is that even if it's not possible to directly determine some of this information, it may be possible to infer it. For instance, consider a scenario where a vulnerability in a service is exposed remotely. There's nothing to stop an attacker from causing the service to crash. In most cases, the service will restart at some predefined point (such as 30 seconds after the crash). Using this approach, an attacker could infer the creation time of the process based on the time that the crash was generated. This isn't fool proof, but it should be possible to get fairly close.

Determining process and thread identifier could be tricky, especially if the system has been up for some time. The author is not aware of a general purpose technique that could be used to determine this information remotely. Fortunately, the process and thread identifier have very little effect on high order bits.

The system uptime is an interesting one. In the past, there have been techniques that could be used to estimate the uptime of the system through the use of TCP timestamps and other network protocol anomalies. At the time of this writing, the author is not aware of how prevalent or useful these techniques are against modern operating systems. Should they still be effective, they would represent a particularly useful way of obtaining a system's uptime. If an attacker can obtain both the creation time of the process and the uptime of the system, it's possible to calculate the tick count and performance counter values with varying degrees of accuracy.

The performance counter will still pose a great challenge in the remote scenario. The reliance on the performance frequency shouldn't be seen as an unknown quantity. As far as the author is aware, the performance frequency on modern processors is generally 3579545, though there may be certain power situations that would cause it to be different.

It is also important to note that the current attack assumes that the load time for an image that has a GS cookie is equivalent to the initial thread's creation time. For example, if a DLL were loaded much later in process execution, such as through instantiating a COM object in Internet Explorer, it would not be possible to assume that initial thread creation time is equal to the system time that was obtained when the DLL's GS cookie was generated. This brings about an interesting point for the remote scenario, however. If an attacker can control the time at which a DLL is loaded, it may be possible for them to infer the value of system time that is used without even having to directly query it. One example of this would be in the context of internet explorer, where the client's date and time functionality might be abused to obtain this information.