Second mremap critical bug
i would have only posted url but it seems to be broken
Synopsis: Linux kernel do_mremap VMA limit local privilege escalation vulnerability Product: Linux kernel Version: 2.2 up to 2.2.25, 2.4 up to 2.4.24, 2.6 up to 2.6.2 Vendor: http://www.kernel.org/ URL: http://isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt CVE: CAN-2004-0077 Author: Paul Starzetz <ihaquer@isec.pl> Date: February 18, 2004 Issue: ====== A critical security vulnerability has been found in the Linux kernel memory management code inside the mremap(2) system call due to missing function return value check. This bug is completely unrelated to the mremap bug disclosed on 05-01-2004 except concerning the same internal kernel function code. Details: ======== The Linux kernel manages a list of user addressable valid memory locations on a per process basis. Every process owns a single linked list of so called virtual memory area descriptors (called from now on just VMAs). Every VMA describes the start of a valid memory region, its length and moreover various memory flags like page protection. Every VMA in the list corresponds to a part of the process's page table. The page table contains descriptors (in short page table entries PTEs) of physical memory pages seen by the process. The VMA descriptor can be thus understood as a high level description of a particular region of the process's page table storing PTE properties like page R/W flag and so on. The mremap() system call provides resizing (shrinking or growing) as well as moving of existing virtual memory areas or any of its parts across process's addressable space. Moving a part of the virtual memory from inside a VMA area to a new location requires creation of a new VMA descriptor as well as copying the underlying page table entries described by the VMA from the old to the new location in the process's page table. To accomplish this task the do_mremap code calls the do_munmap() internal kernel function to remove any potentially existing old memory mapping in the new location as well as to remove the old virtual memory mapping. Unfortunately the code doesn't test the return value of the do_munmap() function which may fail if the maximum number of available VMA descriptors has been exceeded. This happens if one tries to unmap middle part of an existing memory mapping and the process's limit on the number of VMAs has been reached (which is currently 65535). One of the possible situations can be illustrated with the following picture. The corresponding page table entries (PTEs) have been marked with o and x: Before mremap(): (oooooooooooooooooooooooo) (xxxxxxxxxxxx) [----------VMA1----------] [----VMA2----] [REMAPPED-VMA] <---------------| After mremap() without VMA limit: (oooo)(xxxxxxxxxxxx)(oooo) [VMA3][REMAPPED-VMA][VMA4] After mremap() but VMA limit: (ooooxxxxxxxxxxxxxxoooo) [---------VMA1---------] [REMAPPED-VMA] After the maximum number of VMAs in the process's VMA list has been reached do_munmap() will refuse to create the necessary VMA hole because it would split the original VMA in two disjoint VMA areas exceeding the VMA descriptor limit. Due to the missing return value check after trying to unmap the middle of the VMA1 (this is the first invocation of do_munmap inside do_mremap code) the corresponding page table entries from VMA2 are still inserted into the page table location described by VMA1 thus being subject to VMA1 page protection flags. It must be also mentioned that the original PTEs in the VMA1 are lost thus leaving the corresponding page frames unusable for ever. The kernel also tries to insert the overlapping VMA area into the VMA descriptor list but this fails due to further checks in the low level VMA manipulation code. The low level VMA list check in the 2.4 and 2.6 kernel versions just call BUG() therefore terminating the malicious process. There are also two other unchecked calls to do_munmap() inside the do_mremap() code and we believe that the second occurrence of unchecked do_munmap is also exploitable. The second occurrence takes place if the VMA to be remapped is beeing truncated in place. Note that do_munmap can also fail on an exceptional low memory condition while trying to allocate a VMA descriptor. We were able to create a robust proof-of-concept exploit code giving full super-user privileges on all vulnerable kernel versions. The exploit code will be released next week. Impact: ======= Since no special privileges are required to use the mremap(2) system call any process may use its unexpected behavior to disrupt the kernel memory management subsystem. Proper exploitation of this vulnerability leads to local privilege escalation giving an attacker full super-user privileges. The vulnerability may also lead to a denial-of-service attack on the available system memory. Tested and known to be vulnerable kernel versions are all <= 2.2.25, <= 2.4.24 and <= 2.6.1. The 2.2.25 version of Linux kernel does not recognize the MREMAP_FIXED flag but this does not prevent the bug from being successfully exploited. All users are encouraged to patch all vulnerable systems as soon as appropriate vendor patches are released. There is no hotfix for this vulnerablity. Limited per user virtual memory still permits do_munmap() to fail. Credits: ======== Paul Starzetz <ihaquer@isec.pl> has identified the vulnerability and performed further research. COPYING, DISTRIBUTION, AND MODIFICATION OF INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF ONE OF THE AUTHORS. |
...just saw the first POC on some mailinglist.
[edit] On Bugtraq Steve Bremer writes: "I think it's worth noting that those who have been using either the 2.4.23-ow2 or the 2.4.24-ow1 kernel patches from the Openwall Project are not vulnerable to this latest mremap() bug." [edit /] ...just saw the first POC on some mailinglist. Grsecurity-1.9.13 reinforced 2.4.24: ]$ gcc -W -Wall mremap2_poc.c && ./a.out mmap: Cannot allocate memory created ~43577 VMAs kernel may not be vulnerable Someone else care to confirm Grsec results? |
so the 2.6.3 and 2.4.25 kernels contain the fix for this vulnerability?
|
Slack 9.1
Linux kernel 2.4.22 # ./a.out mmap: Cannot allocate memory created ~65530 VMAs now mremapping 0x3FFE5000 at 0x3FFE1000 Segmentation fault # |
I'm not clear on this. Does this or does this not affect kernel 2.6.2???
Thanks kM |
Yes, it affects 2.6.2. It's fixed in 2.6.3.
|
Quote:
- perry |
From the 2.4.25-final changelog:
Andrea Arcangeli: o Return proper do_munmap() error code I assume this is the fix described above? if so the latest 2.4 on kernel.org is patched against it. Someone pls. correct me if I'm wrong, I'm not a big fan of false information :rolleyes: B. |
|
Quote:
|
One of the articles I read said this vulnerability could not be exploited remotely. Does this mean that I probably don't need to worry about patching asap for my home computer?
- Joel |
IS there a kernel patch for 2.4.21, because I have to have a kernel 2.4.21 or before to use the realtek drivers for my wireless lan!
|
I can't find an update for this anywhere from RedHat, does anybody know if the RedHat 7 kernels are vulnerable. I am running 2.4.20-28.7, RH 7.3 and redhat doesn't say that it is affected by this, but doesn't say it isn't. Any ideas? I know that it says that all version <= 2.4.24 are vulnerable, but RedHat has a tendency to use different package naming according to their own fixes. TIA!
Mike. |
I have downloaded the patch from kernel.org, specifically patch-2.6.3.bz2.
I am new to linux and do not know what to do to update the kernel. My distribution is JDS (based on SuSE 8.1 and Linux 2.4.19). |
Quote:
As a side note, you should really upgrade your distro as you won't be able to get official updates from Redhat anymore. While it's not that pressing right now, you could be in for a real world of hurt when the next remote exploit comes out. |
Quote:
http://linux.about.com/library/bl/op...blnewbiea7.htm http://linuxheadquarters.com/howto/t...nelpatch.shtml You might want to either try to find a precompiled binary kernel for your distro, so that you don't have to compile the kernel source or just find the source for a non-vulnerable kernel and compile that without having to patch it. If you have questions about compiling or installing a new kernel, feel free to post them in the Linux-Newbie or Linux-General Forums. |
Quote:
|
It's a local root exploit, so the vulnerability cannot be remotely exploited. But if used in conjunction with an exploit that allows local access, you are done for (or if you already have other users). The recent compromises at debian and gentoo (which used a remote exploit followed by priviledge escalation similar to this one) are good examples of why these types of local root exploits are still extremely dangerous. I would highly recommended upgrading you kernel immediately. Don't let your firewall lull you into the false perception that you are not vulnerable. It certainly minimzes your risk, but you should still upgrade immediately.
|
hey leeach I love the quote. that is so true.:D
2.6.3 and later are uneffected by this bug correct. I'm new so I don't really understand what's going on yet. I'm learing more and more everyday. |
I really am too lazy to fix this right now, I guess I'll just wait until the next kernel comes out, then work with that. I just got my nvidia drivers working, I don't really feel like messing around with that right now.... Thanks for the heads-up though.
|
All times are GMT -5. The time now is 11:08 PM. |