SecurityTracker.com
Keep Track of the Latest Vulnerabilities
with SecurityTracker!
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 
Sign Up
Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Instant Alerts
Buy our Premium Vulnerability Notification Service to receive customized, instant alerts
Affiliates
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Partners
Become a Partner and License Our Database or Notification Service
Report a Bug
Report a vulnerability that you have found to SecurityTracker
bugs
@
securitytracker.com






Category:   OS (Linux)  >   Linux Kernel Vendors:   kernel.org
Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges
SecurityTracker Alert ID:  1009095
SecurityTracker URL:  http://securitytracker.com/id/1009095
CVE Reference:   CAN-2004-0077   (Links to External Site)
Date:  Feb 18 2004
Impact:   Execution of arbitrary code via local system, Root access via local system
Fix Available:  Yes  Vendor Confirmed:  Yes  
Version(s): 2.2 up to 2.2.25, 2.4 up to 2.4.24, 2.6 up to 2.6.2
Description:   Another vulnerability was reported in the Linux kernel do_mremap() function. A local user can execute arbitrary code with root privileges.

Paul Starzetz discovered and reported that there is a missing return value check within the mremap(2) system call.

When resizing or moving virtual memory areas, the function reportedly does not test the return value of the do_munmap() function. Cases where the function fails (for example, due to the number of virtual memory areas being exceeded by the calling process) will not be properly detected, according to the report. As a result, the kernel may move memory belonging to one process into memory space that is allocated to another process.

Some other calls to the do_munmap() function are also not checked, the report said.

A local user can gain root privileges on the target system.

The original advisory is available at:

http://isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt

Impact:   A local user can gain root privileges on the target system.
Solution:   A fixed kernel version (2.4.25, 2.6.3) is available at:

http://www.kernel.org/

Vendor URL:  www.kernel.org/ (Links to External Site)
Cause:   Boundary error
Underlying OS:  

Message History:   This archive entry has one or more follow-up message(s) listed below.
Feb 18 2004 (Debian Issues Fix) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix.
Feb 18 2004 (Trustix Issues Fix) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (Trustix Security Advisor <tsl@trustix.org>)
Trustix has released a fix.
Feb 18 2004 (Red Hat Issues Fix for RH Linux) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (bugzilla@redhat.com)
Red Hat has issued a fix for Red Hat Linux 9.
Feb 18 2004 (Slackware Issues Fix) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (Slackware Security Team <security@slackware.com>)
Slackware has released a fix.
Feb 18 2004 (Debian Issues Fix) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix.
Feb 18 2004 (Debian Issues Fix for mips/mipsel) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix for the mips and mipsel architectures.
Feb 18 2004 (Debian Issues Fix for powerpc/apus) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix for the powerpc/apus architecture.
Feb 18 2004 (Red Hat Issues Fix for RH Enterprise Linux) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (bugzilla@redhat.com)
Red Hat has released a fix for Red Hat Enterprise Linux 2.1.
Feb 18 2004 (SuSE Issues Fix) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (thomas@suse.de (Thomas Biege))
SuSE has released a fix.
Feb 19 2004 (Exploit Code is Available) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (Christophe Devine <devine@iie.cnam.fr>)
Some demonstration exploit code is included.
Feb 20 2004 (Debian Issues Fix for ia64 Architecture) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix for the IA64 architecture.
Feb 25 2004 (Mandrake Issues Fix) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (Mandrake Linux Security Team <security@linux-mandrake.com>)
Mandrake has released a fix.
Feb 26 2004 (Mandrake Issues Fix for x86_64) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (Mandrake Linux Security Team <security@linux-mandrake.com>)
Mandrake has released a fix for Corporate Server 2.1/x86_64.
Feb 27 2004 (Debian Issues Fix for MIPS) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix for the mips architecture.
Mar 3 2004 (Debian Issues Fix) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix for several architectures.
Mar 3 2004 (Debian Issues Fix for Alpha) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix for the alpha architecture.
Mar 3 2004 (SmoothWall Issues Fix) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (William Anderson <neuro@smoothwall.org>)
SmoothWall has issued a fix for Corporate Server and Corporate Guardian.
Mar 6 2004 (Debian Issues Fix for ARM Architecture) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix for Debian Linux 3.0 for the ARM architecture.
Mar 8 2004 (Gentoo Issues Fix) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (Tim Yamin <plasmaroo@gentoo.org>)
Gentoo has released a fix.
Mar 19 2004 (Debian Issues Fix for PowerPC) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix for the PowerPC architecture.
Apr 1 2004 (Debian Issues Fix for HPPA) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix for the hppa architecture.
Apr 2 2004 (VMware Issues Fix) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges
VMware has issued a fix for ESX Server.
Apr 6 2004 (Debian Issues Fix for 2.4.18 HPPA) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix for the 2.4.18 kernel on the HPPA architecture.
Jun 5 2004 (Debian Issues Fix) Linux Kernel do_mremap() Fails to Check do_munmap() Return Values, Allowing a Local User to Gain Root Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix.



 Source Message Contents

Date:  Wed, 18 Feb 2004 13:01:50 +0100 (CET)
Subject:  [Full-Disclosure] Second critical mremap() bug found in all Linux kernels


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.


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)

iD8DBQFAM1QzC+8U3Z5wpu4RAqXzAKCMOkFu1mXzzRgLyuFYp4ORpQCQDgCfe4M2
3IjbGvzniOjv/Hc7KKAzMtU=
=GJds
-----END PGP SIGNATURE-----


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

Copyright 2014, SecurityGlobal.net LLC