10:59 Escalation of privileges in the desktop Linux getting Rutaceae access from guiapplications | |
| A couple of months ago, Rafal Wojtczuk devised a serious exploit, lets get right superyuzera from an unprivileged process, with access to the X-server (that is, from the GUI-application running under normal user). In other words, any GUI-program ( For example, reader PDF-file) if it is to compromise (eg, a specially prepared PDF-file), can break down the barriers of protection on the road to full possession of the computer. Do not save even a sandbox SElinux (SElinux «sandbox-X»). And there is a problem for many years - apparently, with the first versions of the 2.6 kernel. A review of this vulnerability was released on August 17 in [2], and I want to talk about it sometimes in a simplified, sometimes in an expanded form. How it worksThe main reason for this outrage is known for a long time [3]. The problem - especially linuksovskih memory allocation algorithms. As everyone knows, there are two main places where the process can get a piece of the heap - stack and heap (heap). And yet You can select a piece of address space, which does not correspond to physical memory - for this there is a mapping of virtual memory to process files in the filesystem (mmap) or just the abstract kernel objects (System-V style shared memory). It is not necessary even to a dedicated chunk of memory physically existed, at least until the moment when we begin to write it. memory allocation on the x86-32, the image of [3]. x86-64 are all very similar, only bigger scale:) stack - this is the easiest way to allocate memory. As required, it grows from the upper memory to the younger, and if suddenly it turns out that the next page of the stack over, when you try to go there to record the CPU throws a page fault, the kernel allocates a stack for a few more pages (or kills the process if the select failed) . Initially, the stack is given (on x86-32) memory location in the upper part of the address space, the default 128 MB, but in reality, this memory is allocated as needed, and if suddenly all busy elsewhere, malloc () and mmap () are beginning to use "stack" memory. As a result of aggressive allocation may happen that one of the selected sites directly adjacent to the bottom of the stack (which is operated by the property). We now assume that we called some deeply recursive function. The stack pointer begins to approach the border, eventually crossing it and ... nothing happens, because right behind the stack starts we allocated memory. So, we have the stack, which is not really a stack, and a site designated by another way. While all occurred within a single process, the maximum that we can do - it's shit in the process and do something bad with the user account, from which he runs. How to break out of your process and get into the X-serverThe process of X-server (the same / usr/X11/bin/X) runs with the privileges of root. And if we find a way to execute your code in the context of this process, we will reach the intended target. To get a piece of memory in the address space of the X-server, we will use the extension MIT-SHM. In general, the protocol that X-server communicates with client programs, large and of spreading, and contains numerous extensions, invented at different times for different purposes. In particular, MIT-SHM solves a very simple task. Suppose we need to display the large bitmap. To do this, we must somehow send from client to server process many bytes make up the raster (pixmap). But if the client and the server is live on the same machine, it is not necessary to spend resources on copying all of these bytes in the kernel and back, you can instead allocate a shared memory area that will be displayed on the virtual memory of the two processes - these MIT-SHM and deals. We can insidiously take advantage of this API for their own purposes and to display all available memory on the X-server in the address space of approximately thus: shm_seg_size = shmmax while shm_seg_size> = PAGE_SIZE shm_seg = shmget (..., shm_seg_size ,...) prepare and cause XShmAttach (..., shm_seg ...) if not happened, shm_seg_size / = 2 (shmmax is the maximum possible size of memory you can allocate shmget, can be found in / proc / sys / kernel / shmmax) If all is well, one of the selected sites will be accurate for boundary of stack space, but we do not know which one, because the addresses of shared memory on the server side does not like us. To find a tasty morsel, we can pile up the usual means of X-Protocol pyramid of widgets, and then send a command that will recursively (in [2] speaks of a certain function F, which operates recursively, perhaps, this can be found by searching in source code of 'X';)). As a result, the process will come out overseas stack, but no one will notice because these addresses are already allocated XShmAttach. We then its part will review the memory and find the site, which is non-zero bytes (shmget scores allocated to sites with zeros). Now again run the proverbial recursive function F, and while it will work, write to the stack that we like, that is, the new return address. There is already possible to use the classic exploits of technology, such as return-to-libc, the main thing - to replace a stack of time until the function is executed (yes, I know about ASLR, but in this article, we assume that we somehow won;) ) And what do I do?Well, first of all, you can wait for updates. Linus Torvalds (lichno!) added a patch that creates a barrier of unallocated pages between the stack and address space available for the heap and mmap-s. As a result, if not enough memory for the stack, the program attempts to write non-existent address and the fall in SIGBUS (that is, of course, is not very good, but clearly better than a privilege escalation). In kernel 2.6.35.2 and 2.6.34.4, this fix is ??already listed. If for some reason do not want to change the kernel, you can turn off the MIT-SHM in your xorg.conf: Section "Extensions" Option "MIT-SHM" "disable" EndSection True, it does not save us from other possible variations on the same vulnerability. Links
| |
|
| |
| Total comments: 0 | |