linux-kernel - Re: Really good idea to allow mmap(0, FIXED)?

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]

Date:	Thu, 5 Oct 2006 23:55:48 +0000 (UTC)
From:	daw@...berkeley.edu (David Wagner)
To:	linux-kernel@...r.kernel.org
Subject: Re: Really good idea to allow mmap(0, FIXED)?

Michael Buesch  wrote:
>Is is really a good idea to allow processes to remap something
>to address 0?
>I say no, because this can potentially be used to turn rather harmless
>kernel bugs into a security vulnerability.

Let me see if I understand.  If the kernel does this somewhere:

    struct s *foo;
    foo->x->y = 0;

and if there is some way that userland code can cause this to be
executed with 'foo' set to a NULL pointer, then user-land code can
do this:

    mmap(0, 4096, PROT_READ|PROT_EXEC|PROT_WRITE,
        MAP_FIXED|MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
    struct s *bar = 0;
    bar->x = ... whatever ...;

An attacker could execute this user-land code and then invoke the
kernel in a way that causes the above kernel statement to be executed
with foo==NULL.  The result will effectively be as though the kernel
executed the statement '*whatever = 0;', where 'whatever' can be
completely controlled by the attacker.

In other words, the consequences of the buggy kernel code listed above
is that an attacker can choose any location in memory (of his choice,
including code that is within kernel space) and set it to zero.

If this is correct so far, this sounds pretty dangerous.  For instance,
the above hypothetical scenario would be enough to allow an attacker
to set his euid to zero by overwriting the euid field in the process
structure maintained by the kernel.  That would mean that a NULL pointer
bug in the kernel might allow an attacker to gain root.  That would
mean that every NULL pointer dereference bug is potentially security
critical.  If so, we'd better be pretty darn careful to make sure we've
eliminated all NULL pointer bugs in the kernel.

Is this right?  Have I correctly understood the issue?
-
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/