Getting Root on Multiprocessor Machines

Now, consider another interesting vulnerability typical for kernels version 2.4/2.6 on multiprocessor machines. It was detected early in 2005 and remains urgent because not all administrators have installed appropriate patches and because multi-processor machines (including microprocessors with support for Hyper-Threading technology) are more the rule than the exception.

The main responsibility for this bug is attributed to the page fault handler, which is called any time an application accesses an unallocated or protected memory page. Not all errors are equally fatal. In particular, Linux (like most other systems) doesn't allocate the entire stack memory in a single-stage operation. Rather, it does this in parts . On the top of the allocated memory there is a page, access to which is intentionally disallowed . This page is called the guard page (GUARD_PAGE). Gradually, the stack grows. At a certain moment, it "hits" the guard page, causing an exception. This exception is trapped by the page fault handler, and the operating system allocates some memory to the stack, moving the guard page upward. On uniprocessor machines, this mechanism works excellently; however, with multiprocessor computers there are problems (Listing 14.6).

Listing 14.6: Key fragment of the /mm/fault.c function containing a synchronization error

 down_read(&mm->mmap_sem); /* * */ vma - find_vma(mm, address); . if (!vma)         goto bad_area; if (vma->vm_start <= address) goto good_area; if (!(vma->vm_flags & VM_GROWSDOWN))         goto bad_area; if (error_code & 4) { /* * Accessing the stack below %esp is always a bug. * The "+ 32" is there because of some instructions (like * PUSHA) doing postdecrement on the stack, and that * doesn't show up until later. */ if (address + 32 < regs->esp) /* * */         goto bad_area; } if (expand_stack(vma, address))          goto bad_area; 

 

Because the page fault handler is executed with the read-only semaphore, the situation is possible when several concurrent threads simultaneously enter the handler after the /* * */ string. Consider what happens if two threads sharing the same virtual memory simultaneously call the fault handler. The attack scenario appears approximately as follows . Thread 1 accesses the GUARD_PAGE page and cause the fault_1 exception. Thread 2 accesses the GUARD_PAGE + PAGE_SIZE page and causes the fault_2 exception.

The virtual memory state in this case would appear as shown in Fig. 14.1.

Figure 14.1: The virtual memory state when the page fault handler is called by two concurrent threads

If thread_2 takes the lead over thread_l and allocates its page PAGE1 first, thread_1 will cause a serious problem with the virtual memory manager operation, because after that the lower boundary of the stack will be located higher than fault_2 . Therefore, the PAGE2 page is not allocated but becomes available for reading and writing to both threads; furthermore, it won't be deleted after process termination (Fig. 14.2).

Figure 14.2: The virtual memory state at the moment of the page fault handler exit

What is located in PAGE2? This depends on the state of the page table. Because in Linux physical memory is a kind of the virtual address state cache, the same page at different times can be used both by the kernel and by user applications (including privileged processes).

Having waited until the kernel code or some privileged process falls into PAGE2 (this can be easily determined by its signature), the hacker can insert some shell-code here or simply organize a DoS attack by filling PAGE2 with senseless garbage. Although this vulnerability has been known for a long time, I didn't manage to find a ready-to-use exploit for it. However, a true hacker can easily write a custom exploit. A detailed description of this vulnerability is provided at the following address: http://www.isec.pl/vulnerabilities/isec-0022-pagefault.txt .