Uninformed: Informative Information for the Uninformed

Vol 9» 2008.Jan

Next: Weaknesses Up: Temporal Keys Previous: Temporal Keys

Context-Key Selection

Provided by the previously mentioned temporal return address research effort is a very useful tool called telescope[16, 8]. The tool's function is to analyze a running process' memory for potential temporal addresses and report them to the user. By using this tool, potential context-key values and the addresses at which they reside can be respectively predicted and identified.

The temporal return addresses paper also revealed a section of memory that is mapped into all processes running on Windows NT, or any other more recent Windows system, called SharedUserData[16, 17]. The interesting properties of the SharedUserData region of a process' address space is that it is always mapped into memory at a predictable location and is required to be backwards compatible with previous versions. As such, the individual values contained within the region will always be at the same offset to it's predictable base address. One of the values contained within this region of memory is the system time, which will be used in the examples to follow.

Remotely Determining Time

Methods and techniques for profiling a target system's current time is outside of the scope of this paper, however the aforementioned paper on temporal return addresses[16, 13-15] offers some insight. Once a target system's current time has been identified, the values found at various temporal addresses in memory can be readily predicted to varying degrees of accuracy.

Time-Window Selection

It is important to note that when using data stored at a temporal address as a context-key, parts of that value are likely to be changing frequently. Fortunately, the key length being used may not require use of the entire timer value, and as such the values found at the byte offsets that are frequently changing can likely be ignored. Consider the SystemTime value from the Windows SharedUserData region of memory. SystemTime is a 100 nanosecond timer which is measured from January 1st, 1601, is stored as a _KSYSTEM_TIME structure, and is located at memory address 0x7ffe0014 on all versions of Windows NT[16, 16]:

0:000> dt _KSYSTEM_TIME
   +0x000 LowPart          : Uint4B
   +0x004 High1Time        : Int4B
   +0x008 High2Time        : Int4B

Due to this timer's frequent update period, granularity, and scale, some of the data contained at the temporal address will be too transient for use as a context-key. The capacity of SystemTime is twelve bytes, however due to the four bytes labeled as High2Time having an identical value as the four bytes labeled as High1Time, only the first eight bytes are relevant as a timer. As shown by the calculations provided by the temporal return addresses paper[16, 10], reproduced below as Figure 1, it is only worth focusing on values beginning at byte index four of the SystemTime value, or the four bytes labeled as High1Time located at address 0x7ffe0018.

Figure 1: 8 byte 100ns per-byte duration in seconds
\begin{tabular}{\vert c\vert l\vert}
\hline Byte & ...
...59403 (228 years 179 days)\\

It is also interesting to note that if the payload encoder only utilizes a single byte context-key, it may not even be required that the attacker determine the target system's time, as the value at byte index six or seven of the SystemTime value could be used requiring only that the attacker guess the system time to within a little less than a year, or to within 228 years, respectively.