[33836] in bugtraq
Re: Second critical mremap() bug found in all Linux kernels
daemon@ATHENA.MIT.EDU (Dan Yefimov)
Thu Feb 19 13:57:31 2004
Date: Thu, 19 Feb 2004 07:24:43 +0300 (MSK)
From: Dan Yefimov <dan@D00M.integrate.com.ru>
To: security@isec.pl
Cc: full-disclosure@lists.netsys.com, <vulnwatch@vulnwatch.org>,
<bugtraq@securityfocus.com>
In-Reply-To: <Pine.LNX.4.44.0402181250420.21492-100000@isec.pl>
Message-ID: <Pine.LNX.4.44.0402190642510.15577-200000@D00M.integrate.com.ru>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-90297078-1829702243-1077163091=:15577"
Content-ID: <Pine.LNX.4.44.0402190724350.15577@D00M.integrate.com.ru>
---90297078-1829702243-1077163091=:15577
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.44.0402190724351.15577@D00M.integrate.com.ru>
On Wed, 18 Feb 2004, Paul Starzetz wrote:
> -----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-----
>
>
Attached patch fixes this bug for kernel 2.2.25. It should also apply cleanly to
kernels since at least 2.2.21.
--
Sincerely Your, Dan.
---90297078-1829702243-1077163091=:15577
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="linux-2.2.25-mremap-security.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.44.0402190658110.15577@D00M.integrate.com.ru>
Content-Description: Patch to fix mremap() bug for kernel 2.2.25
Content-Disposition: ATTACHMENT; FILENAME="linux-2.2.25-mremap-security.patch"
LS0tIGxpbnV4L21tL21yZW1hcC5jLnNlY3VyaXR5CVN1biBNYXIgMjUgMjA6
MzE6MDMgMjAwMQ0KKysrIGxpbnV4L21tL21yZW1hcC5jCVRodSBGZWIgMTkg
MDU6MTA6MzQgMjAwNA0KQEAgLTksNiArOSw3IEBADQogI2luY2x1ZGUgPGxp
bnV4L3NobS5oPg0KICNpbmNsdWRlIDxsaW51eC9tbWFuLmg+DQogI2luY2x1
ZGUgPGxpbnV4L3N3YXAuaD4NCisjaW5jbHVkZSA8bGludXgvZmlsZS5oPg0K
IA0KICNpbmNsdWRlIDxhc20vdWFjY2Vzcy5oPg0KICNpbmNsdWRlIDxhc20v
cGd0YWJsZS5oPg0KQEAgLTI1LDcgKzI2LDcgQEANCiAJaWYgKHBnZF9ub25l
KCpwZ2QpKQ0KIAkJZ290byBlbmQ7DQogCWlmIChwZ2RfYmFkKCpwZ2QpKSB7
DQotCQlwcmludGsoIm1vdmVfb25lX3BhZ2U6IGJhZCBzb3VyY2UgcGdkICgl
MDhseClcbiIsIHBnZF92YWwoKnBnZCkpOw0KKwkJcHJpbnRrKCJjb3B5X29u
ZV9wYWdlOiBiYWQgc291cmNlIHBnZCAoJTA4bHgpXG4iLCBwZ2RfdmFsKCpw
Z2QpKTsNCiAJCXBnZF9jbGVhcihwZ2QpOw0KIAkJZ290byBlbmQ7DQogCX0N
CkBAIC0zNCw3ICszNSw3IEBADQogCWlmIChwbWRfbm9uZSgqcG1kKSkNCiAJ
CWdvdG8gZW5kOw0KIAlpZiAocG1kX2JhZCgqcG1kKSkgew0KLQkJcHJpbnRr
KCJtb3ZlX29uZV9wYWdlOiBiYWQgc291cmNlIHBtZCAoJTA4bHgpXG4iLCBw
bWRfdmFsKCpwbWQpKTsNCisJCXByaW50aygiY29weV9vbmVfcGFnZTogYmFk
IHNvdXJjZSBwbWQgKCUwOGx4KVxuIiwgcG1kX3ZhbCgqcG1kKSk7DQogCQlw
bWRfY2xlYXIocG1kKTsNCiAJCWdvdG8gZW5kOw0KIAl9DQpAQCAtNTcsMzQg
KzU4LDIyIEBADQogCXJldHVybiBwdGU7DQogfQ0KIA0KLXN0YXRpYyBpbmxp
bmUgaW50IGNvcHlfb25lX3B0ZShwdGVfdCAqIHNyYywgcHRlX3QgKiBkc3Qp
DQorc3RhdGljIGludCBjb3B5X29uZV9wYWdlKHN0cnVjdCBtbV9zdHJ1Y3Qg
Km1tLCB1bnNpZ25lZCBsb25nIG9sZF9hZGRyLCB1bnNpZ25lZCBsb25nIG5l
d19hZGRyKQ0KIHsNCi0JaW50IGVycm9yID0gMDsNCi0JcHRlX3QgcHRlID0g
KnNyYzsNCisJcHRlX3QgKiBzcmMsICogZHN0Ow0KIA0KLQlpZiAoIXB0ZV9u
b25lKHB0ZSkpIHsNCi0JCWVycm9yKys7DQotCQlpZiAoZHN0KSB7DQotCQkJ
cHRlX2NsZWFyKHNyYyk7DQotCQkJc2V0X3B0ZShkc3QsIHB0ZSk7DQotCQkJ
ZXJyb3ItLTsNCisJc3JjID0gZ2V0X29uZV9wdGUobW0sIG9sZF9hZGRyKTsN
CisJaWYgKHNyYyAmJiAhcHRlX25vbmUoKnNyYykpIHsNCisJCWlmICgoZHN0
ID0gYWxsb2Nfb25lX3B0ZShtbSwgbmV3X2FkZHIpKSkgew0KKwkJCXNldF9w
dGUoZHN0LCAqc3JjKTsNCisJCQlyZXR1cm4gMDsNCiAJCX0NCisJCXJldHVy
biAxOw0KIAl9DQotCXJldHVybiBlcnJvcjsNCi19DQotDQotc3RhdGljIGlu
dCBtb3ZlX29uZV9wYWdlKHN0cnVjdCBtbV9zdHJ1Y3QgKm1tLCB1bnNpZ25l
ZCBsb25nIG9sZF9hZGRyLCB1bnNpZ25lZCBsb25nIG5ld19hZGRyKQ0KLXsN
Ci0JaW50IGVycm9yID0gMDsNCi0JcHRlX3QgKiBzcmM7DQotDQotCXNyYyA9
IGdldF9vbmVfcHRlKG1tLCBvbGRfYWRkcik7DQotCWlmIChzcmMpDQotCQll
cnJvciA9IGNvcHlfb25lX3B0ZShzcmMsIGFsbG9jX29uZV9wdGUobW0sIG5l
d19hZGRyKSk7DQotCXJldHVybiBlcnJvcjsNCisJcmV0dXJuIDA7DQogfQ0K
IA0KLXN0YXRpYyBpbnQgbW92ZV9wYWdlX3RhYmxlcyhzdHJ1Y3QgbW1fc3Ry
dWN0ICogbW0sDQorc3RhdGljIGludCBjb3B5X3BhZ2VfdGFibGVzKHN0cnVj
dCBtbV9zdHJ1Y3QgKiBtbSwNCiAJdW5zaWduZWQgbG9uZyBuZXdfYWRkciwg
dW5zaWduZWQgbG9uZyBvbGRfYWRkciwgdW5zaWduZWQgbG9uZyBsZW4pDQog
ew0KIAl1bnNpZ25lZCBsb25nIG9mZnNldCA9IGxlbjsNCkBAIC05OSw3ICs4
OCw3IEBADQogCSAqLw0KIAl3aGlsZSAob2Zmc2V0KSB7DQogCQlvZmZzZXQg
LT0gUEFHRV9TSVpFOw0KLQkJaWYgKG1vdmVfb25lX3BhZ2UobW0sIG9sZF9h
ZGRyICsgb2Zmc2V0LCBuZXdfYWRkciArIG9mZnNldCkpDQorCQlpZiAoY29w
eV9vbmVfcGFnZShtbSwgb2xkX2FkZHIgKyBvZmZzZXQsIG5ld19hZGRyICsg
b2Zmc2V0KSkNCiAJCQlnb3RvIG9vcHNfd2VfZmFpbGVkOw0KIAl9DQogCXJl
dHVybiAwOw0KQEAgLTExMyw4ICsxMDIsNiBAQA0KIAkgKi8NCiBvb3BzX3dl
X2ZhaWxlZDoNCiAJZmx1c2hfY2FjaGVfcmFuZ2UobW0sIG5ld19hZGRyLCBu
ZXdfYWRkciArIGxlbik7DQotCXdoaWxlICgob2Zmc2V0ICs9IFBBR0VfU0la
RSkgPCBsZW4pDQotCQltb3ZlX29uZV9wYWdlKG1tLCBuZXdfYWRkciArIG9m
ZnNldCwgb2xkX2FkZHIgKyBvZmZzZXQpOw0KIAl6YXBfcGFnZV9yYW5nZSht
bSwgbmV3X2FkZHIsIGxlbik7DQogCWZsdXNoX3RsYl9yYW5nZShtbSwgbmV3
X2FkZHIsIG5ld19hZGRyICsgbGVuKTsNCiAJcmV0dXJuIC0xOw0KQEAgLTEy
OSw3ICsxMTYsOSBAQA0KIAlpZiAobmV3X3ZtYSkgew0KIAkJdW5zaWduZWQg
bG9uZyBuZXdfYWRkciA9IGdldF91bm1hcHBlZF9hcmVhKGFkZHIsIG5ld19s
ZW4pOw0KIA0KLQkJaWYgKG5ld19hZGRyICYmICFtb3ZlX3BhZ2VfdGFibGVz
KGN1cnJlbnQtPm1tLCBuZXdfYWRkciwgYWRkciwgb2xkX2xlbikpIHsNCisJ
CWlmIChuZXdfYWRkciAmJiAhY29weV9wYWdlX3RhYmxlcyhjdXJyZW50LT5t
bSwgbmV3X2FkZHIsIGFkZHIsIG9sZF9sZW4pKSB7DQorCQkJdW5zaWduZWQg
bG9uZyByZXQ7DQorDQogCQkJKm5ld192bWEgPSAqdm1hOw0KIAkJCW5ld192
bWEtPnZtX3N0YXJ0ID0gbmV3X2FkZHI7DQogCQkJbmV3X3ZtYS0+dm1fZW5k
ID0gbmV3X2FkZHIrbmV3X2xlbjsNCkBAIC0xMzgsOSArMTI3LDE5IEBADQog
CQkJCW5ld192bWEtPnZtX2ZpbGUtPmZfY291bnQrKzsNCiAJCQlpZiAobmV3
X3ZtYS0+dm1fb3BzICYmIG5ld192bWEtPnZtX29wcy0+b3BlbikNCiAJCQkJ
bmV3X3ZtYS0+dm1fb3BzLT5vcGVuKG5ld192bWEpOw0KKwkJCWlmICgocmV0
ID0gZG9fbXVubWFwKGFkZHIsIG9sZF9sZW4pKSkgew0KKwkJCQlpZiAobmV3
X3ZtYS0+dm1fb3BzICYmIG5ld192bWEtPnZtX29wcy0+Y2xvc2UpDQorCQkJ
CQluZXdfdm1hLT52bV9vcHMtPmNsb3NlKG5ld192bWEpOw0KKwkJCQlpZiAo
bmV3X3ZtYS0+dm1fZmlsZSkNCisJCQkJCWZwdXQobmV3X3ZtYS0+dm1fZmls
ZSk7DQorCQkJCWZsdXNoX2NhY2hlX3JhbmdlKGN1cnJlbnQtPm1tLCBuZXdf
YWRkciwgbmV3X2FkZHIgKyBvbGRfbGVuKTsNCisJCQkJemFwX3BhZ2VfcmFu
Z2UoY3VycmVudC0+bW0sIG5ld19hZGRyLCBvbGRfbGVuKTsNCisJCQkJZmx1
c2hfdGxiX3JhbmdlKGN1cnJlbnQtPm1tLCBuZXdfYWRkciwgbmV3X2FkZHIg
KyBvbGRfbGVuKTsNCisJCQkJa21lbV9jYWNoZV9mcmVlKHZtX2FyZWFfY2Fj
aGVwLCBuZXdfdm1hKTsNCisJCQkJcmV0dXJuIHJldDsNCisJCQl9DQogCQkJ
aW5zZXJ0X3ZtX3N0cnVjdChjdXJyZW50LT5tbSwgbmV3X3ZtYSk7DQogCQkJ
bWVyZ2Vfc2VnbWVudHMoY3VycmVudC0+bW0sIG5ld192bWEtPnZtX3N0YXJ0
LCBuZXdfdm1hLT52bV9lbmQpOw0KLQkJCWRvX211bm1hcChhZGRyLCBvbGRf
bGVuKTsNCiAJCQljdXJyZW50LT5tbS0+dG90YWxfdm0gKz0gbmV3X2xlbiA+
PiBQQUdFX1NISUZUOw0KIAkJCWlmIChuZXdfdm1hLT52bV9mbGFncyAmIFZN
X0xPQ0tFRCkgew0KIAkJCQljdXJyZW50LT5tbS0+bG9ja2VkX3ZtICs9IG5l
d19sZW4gPj4gUEFHRV9TSElGVDsNCkBAIC0xNzYsOSArMTc1LDkgQEANCiAJ
ICogQWx3YXlzIGFsbG93IGEgc2hyaW5raW5nIHJlbWFwOiB0aGF0IGp1c3Qg
dW5tYXBzDQogCSAqIHRoZSB1bm5lY2Vzc2FyeSBwYWdlcy4uDQogCSAqLw0K
LQlyZXQgPSBhZGRyOw0KIAlpZiAob2xkX2xlbiA+PSBuZXdfbGVuKSB7DQot
CQlkb19tdW5tYXAoYWRkcituZXdfbGVuLCBvbGRfbGVuIC0gbmV3X2xlbik7
DQorCQlpZiAoIShyZXQgPSBkb19tdW5tYXAoYWRkcituZXdfbGVuLCBvbGRf
bGVuIC0gbmV3X2xlbikpKQ0KKwkJCXJldCA9IGFkZHI7DQogCQlnb3RvIG91
dDsNCiAJfQ0KIA0K
---90297078-1829702243-1077163091=:15577--
