[VulnWatch] Second critical mremap() bug found in all Linux kernels

From: Paul Starzetz (ihaquer_at_isec.pl)
Date: 02/18/04

  • Next message: Ulf Härnhammar: "[VulnWatch] metamail format string bugs and buffer overflows"
    Date: Wed, 18 Feb 2004 13:01:50 +0100 (CET)
    To: full-disclosure@lists.netsys.com, <vulnwatch@vulnwatch.org>, <bugtraq@securityfocus.com>

    Hash: SHA1

    Synopsis: Linux kernel do_mremap VMA limit local privilege escalation
    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


    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.


    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:


    After mremap() but VMA limit:


    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

    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.


    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.


    Paul Starzetz <ihaquer@isec.pl> has identified the vulnerability and
    performed further research. COPYING, DISTRIBUTION, AND MODIFICATION OF


    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

    Version: GnuPG v1.0.7 (GNU/Linux)

    -----END PGP SIGNATURE-----

  • Next message: Ulf Härnhammar: "[VulnWatch] metamail format string bugs and buffer overflows"