Linux ASLR vulnerabilities

A recent LWN comment thread—which unfortunately descended into flames and rudeness—had a post with some interesting pointers to recent security research on Linux address space layout randomization (ASLR). Both look to be plausible attacks against ASLR, and have not yet been addressed by the kernel hackers. Perhaps worse than that, though, is that these kinds of problems are evidently not being reported to linux-kernel (or other kernel security channels), or not being acted on. Over the years, the interaction of security researchers and kernel hackers has often been contentious, to the point where some security researchers may not be reporting the Linux flaws they find via the usual channels.

ASLR is a technique used to thwart buffer overflow vulnerabilities in user applications by randomizing the location of various pieces of the application's address space. Libraries, the heap and stack, as well as the executable code for a process are placed at random addresses so that attacker programs have a much more difficult time exploiting a buffer overflow. Without the use of ASLR, an attack could use hardcoded addresses of known locations in a process's address space (e.g. specific library functions) to perform its nefarious deeds.

It is important that attacker programs be unable to see—or figure out—the memory layout for other processes in the system. Attackers who can gain that information could then use any buffer overflows they know of for that program with all of the addresses they need. For that reason, /proc/pid/maps (a file that describes the address space for process id pid) only contains data when read by the owner of that pid—or someone who can ptrace() it. A recent advisory about memcache and memcacheDB divulging that information, unauthenticated over the network should be worrisome for just this reason.

The decision to stop allowing anyone to read the maps file came about in 2.6.22, long after ASLR was added in 2.6.12. Based on a presentation [PDF] at this year's CanSecWest conference, there is still enough information being leaked from /proc files to be able to determine the address space layout for a program.

The /proc/pid/stat file reports the value of the instruction and stack pointers of the process, and the /proc/pid/wchan file reports its "wait channel", which is the function in which the process is currently blocked. Using that information, possibly sampled multiple times, along with a map of the instruction boundaries of the executable, Julien Tinnes and Tavis Ormandy were able to bypass ASLR.

The second flaw in ASLR was presented at Black Hat Europe by Hagen Fritsch. A whitepaper [PDF] describing the flaw is instructive. Essentially, the random number generator (RNG) used to create the addresses for ASLR is flawed, allowing those values to be correctly calculated up to two minutes after a target process has been run.

There is clearly a disconnect between the comment in the get_random_int() function (which uses the IP RNG secure_ip_id()) and the implementation of re-keying the RNG in drivers/char/random.c. The former claims that it gets re-keyed every second, but the REKEY_INTERVAL in the random driver is five minutes. If ASLR requires the RNG to re-key every second, a different function should be used. But, there is an additional problem.

The secure_ip_id() function takes one argument which it mixes with the key in order to generate the random number. get_random_int() passes the sum of the pid and the internal kernel counter jiffies as that parameter. For a period of five minutes, if the attacker can arrange for the same sum to be passed in, they will get the same value as the target process did. That can happen in one of two ways: either by calling execve() on the desired target within one jiffy of when the attack process started—a rather difficult thing to arrange for a number of reasons—or by calling execve() when pid + jiffies is the same as it was for the target process.

An attacker process can spawn children until it gets a desired pid, then wait for jiffies to reach a value where the sum is the same. Even though the absolute value of jiffies is not known outside of the kernel, various calculations on the difference in jiffie values can be used to narrow down the search. Once again, the /proc/pid/stat file can come into play here, by providing a start time for the target process with a granularity typically 2.5 times that of jiffies (10ms vs. 4ms).

In addition, Fritsch notes that IP sequence numbers may be leaking information that could be used to assist in this attack because it uses the same RNG with the five minute re-key time. He has not looked at whether that is the case.

These two vulnerabilities are fairly substantial and should certainly be fixed. It would seem fairly straightforward to limit access to the /proc files based on the same ptrace() test used for maps. The RNG flaw is more subtle and probably requires a fair amount of thought, but it is clear that the randomness provided is insufficient, at least for ASLR.

Another report that came out of the comment thread demonstrates a misclassification of security flaws that tends to be very annoying to the security community. Misclassifying remotely exploitable flaws as a "denial of service" (due to a kernel crash) is a fairly common thing for distributions and others (knowingly or not) to do. As the blog posting indicates, it irritates some researchers:

That particular vulnerability is long fixed in the kernel, but the whole posting is worth a read for those interested in how a kernel buffer overflow can become a remote root exploit (even bypassing SELinux). It is also indicative of the frustration that some in the security community feel about Linux security. For good or ill, Linux security is not well regarded in that community, to the point where it appears that some, possibly large, amount of Linux kernel security research is not being communicated to the kernel community. Perhaps that communication is occurring but is just "flying under the radar"—something that frequently happens with security discussions—as it would be a tragedy to think that known vulnerabilities are just falling through the cracks.