linux-kernel - Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.1.10.0906031047390.15621@gentwo.org>
Date:	Wed, 3 Jun 2009 10:50:46 -0400 (EDT)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	"Larry H." <research@...reption.com>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>, linux-mm@...ck.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org,
	pageexec@...email.hu
Subject: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR
 to point at unmapped space)

On Tue, 2 Jun 2009, Larry H. wrote:

> Why would mmap_min_addr have been created in first place, if NULL can't
> be mapped to force the kernel into accessing userland memory? This is
> the way a long list of public and private kernel exploits have worked to
> elevate privileges, and disable SELinux/LSMs atomically, too.
>
> Take a look at these:
> http://www.grsecurity.net/~spender/exploit.tgz (disables LSMs)
> http://milw0rm.com/exploits/4172
> http://milw0rm.com/exploits/3587
>
> I would like to know what makes you think I can't mmap(0) from within
> the same process that triggers your 'not so exploitable NULL page
> fault', which instead of generating the oops will lead to 100% reliable,
> cross-arch exploitation to get root privileges (again, after disabling
> SELinux and anything else that would supposedly prevent this situation).
> Or leaked memory, like a kmalloc(0) situation will most likely lead to,
> given the current circumstances.

Ok. So what we need to do is stop this toying around with remapping of
page 0. The following patch contains a fix and a test program that
demonstrates the issue.


Subject: [Security] Do not allow remapping of page 0 via MAP_FIXED

If one remaps page 0 then the kernel checks for NULL pointers of various
flavors are bypassed and this may be exploited in various creative ways
to transfer data from kernel space to user space.

Fix this by not allowing the remapping of page 0. Return -EINVAL if
such a mapping is attempted.

Simple test program that shows the problem:

#include <sys/mman.h>

int main(int argc, char *argv)
{
        printf("%ld\n", mmap(0L, 4096, PROT_WRITE, MAP_FIXED|MAP_PRIVATE|MAP_ANONYMOUS, 0,0));
        *((char *)8) = 3;
        printf("Value at address 8 is %d\n", *((char *)8));
        return 0;
}

If the remapping of page 0 succeeds then the value at 8 is 3.
After the patch the program segfaults as it should.

Signed-off-by: Christoph Lameter <cl@...ux-foundation.org>

---
 mm/mmap.c |   16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

Index: linux-2.6/mm/mmap.c
===================================================================
--- linux-2.6.orig/mm/mmap.c	2009-06-03 09:44:43.000000000 -0500
+++ linux-2.6/mm/mmap.c	2009-06-03 09:45:31.000000000 -0500
@@ -1273,8 +1273,12 @@ arch_get_unmapped_area(struct file *filp
 	if (len > TASK_SIZE)
 		return -ENOMEM;

-	if (flags & MAP_FIXED)
-		return addr;
+	if (flags & MAP_FIXED) {
+		if (addr & PAGE_MASK)
+			return addr;
+		/* Do not allow remapping of the first page */
+		return -EINVAL;
+	}

 	if (addr) {
 		addr = PAGE_ALIGN(addr);
@@ -1349,8 +1353,12 @@ arch_get_unmapped_area_topdown(struct fi
 	if (len > TASK_SIZE)
 		return -ENOMEM;

-	if (flags & MAP_FIXED)
-		return addr;
+	if (flags & MAP_FIXED) {
+		if (addr & PAGE_MASK)
+			return addr;
+		/* Do not allow remapping of the first page */
+		return -EINVAL;
+	}

 	/* requesting a specific address */
 	if (addr) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/