Attachment 15737 Details for Bug 49117

post from Paul to vendor-sec

mremap-bug2.txt (text/plain), 6.51 KB, created by Thomas Biege on 2004-01-23 20:58:24 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Thomas Biege

Created: 2004-01-23 20:58:24 UTC

Size: 6.51 KB

patch

obsolete

>From ihaquer@isec.pl Fri Jan 23 13:56:04 2004
>Date: Fri, 23 Jan 2004 13:40:20 +0100 (CET)
>From: Paul Starzetz <ihaquer@isec.pl>
>Reply-To: security@isec.pl
>To: vendor-sec <vendor-sec@lst.de>
>Subject: [vendor-sec] Another serious mremap() vulnerability
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Synopsis:  Linux kernel do_mremap VMA limit local privilege escalation
>           vulnerability
>Product:   Linux kernel
>Version:   2.4 up to 2.4.24 and 2.6.0
>Vendor:    http://www.kernel.org/
>URL:       not assigned
>CVE:       not assigned
>Author:    Paul Starzetz <ihaquer@isec.pl>, Wojciech Purczynski
>           <cliph@isec.pl>
>Date:      January 23, 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 5.1.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 particual 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. 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 
>the new VMA location goes into the middle of an existing memory mapping 
>and the process's limit on the number of VMAs has been reached (which is 
>currently 65535).
>
>This can be illustrated with the following ASCII-art picture where the 
>corresponding page table entries (PTEs) have been marked with X/Y:
>
>Before mremap():
>
>(YYYYYYYYYYYYYYYYYYYYYYYY)     (XXXXXXXXXXXXX)
>[----------VMA1----------]     [-----VMA2----]
>      [REMAPPED-VMA] <---------------|
>
>
>After mremap() without VMA limit:
>
>(YYYY)(XXXXXXXXXXXX)(YYYY)
>[VMA3][REMAPPED-VMA][VMA4]
>
>
>After mremap() but VMA limit:
>
>(YYYYYXXXXXXXXXXXXYYYYY)
>[---------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) 
>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 locked 
>in memory.
>
>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.
>
>We were able to create a proof-of-concept exploit code moving page table 
>entries from one VMA to another one with different PTE protection flags. 
>The moved page table entries could be then manipulated for example to 
>gain write access to normaly read-only pages mapping disk files like 
>/etc/passwd and so on.
>
>There are also two other unchecked calls to do_munmap() and we believe 
>that the second occurence of unchecked do_munmap is very easily 
>exploitable. The second occurence takes place if the VMA to be remapped 
>is beeing truncated in place. However do_munmap can also fail on an 
>execptional low memory condition while trying to preallocate a VMA 
>descriptor.
>
>
>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 may lead to local privilege 
>escalation giving an attacker full super-user privileges but may also 
>include execution of arbitrary code with kernel level access. The 
>vulnerability leads also to a denial-of-service attack on the available 
>system memory.
>
>Tested and known to be vulnerable kernel versions are all <= 2.4.24 and 
>2.6.0. All users are encouraged to patch all vulnerable systems as soon 
>as appropriate vendor patches are released.
>
>
>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.
>
>
>Disclaimer:
>===========
>
>This document and all the information it contains are provided "as is", 
>for educational purposes only, without warranty of any kind, whether 
>express or implied.
>
>The authors reserve the right not to be responsible for the topicality, 
>correctness, completeness or quality of the information  provided in 
>this document. Liability claims regarding damage caused by the use of 
>any information provided, including any kind of information which is 
>incomplete or incorrect, will therefore be rejected.
>
>- -- 
>Paul Starzetz
>iSEC Security Research
>http://isec.pl/
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.7 (GNU/Linux)
>
>iD8DBQFAERY5C+8U3Z5wpu4RAnmvAJ93n73Fi8BBpYZgvTUF21DVMonjKQCg1MBY
>HyvaD+vttT7Y3bLX2r/JKnQ=
>=mO5q
>-----END PGP SIGNATURE-----
>
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec

Actions: View

Attachments on bug 49117: 15737 | 15808 | 16076