From: Michael Buesch <mb@bu3sch.de>
To: "linux-kernel" <linux-kernel@vger.kernel.org>
Subject: Re: Really good idea to allow mmap(0, FIXED)?
Date: Fri, 6 Oct 2006 16:55:32 +0200 [thread overview]
Message-ID: <200610061655.32249.mb@bu3sch.de> (raw)
In-Reply-To: <200610052059.11714.mb@bu3sch.de>
Ok, some people have good points against special casing
address 0 here. That's fine.
But: I think, if we don't protect from remapping address 0,
we should _really_ take NULL pointer dereference bugs more serious.
Every NULL pointer dereference bug should be checked for the
possibility of unprivileged users controlling the kernel.
I think currently NULL pointer dereferece bugs are not seen as
a security vulnerability by most people. In future we
should look at the bugs more closely and check if this is a
security vulnerability or just a "crash my app" bug.
On Thursday 05 October 2006 20:59, Michael Buesch wrote:
> Hi,
>
> This question has already been discussed here in the past, but
> we did not come to a good result. So I want to ask the question again:
>
> 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's say we have some kernel NULL pointer dereference bug somewhere,
> that's rather harmless, if it happens in process context and
> does not leak any resources on segfaulting the triggering app.
> So the worst thing that happens is a crashing app. Yeah, this bug must
> be fixed. But my point is that this bug can probably be used to
> manipulate the way the kernel works or even to inject code into
> the kernel from userspace.
>
> Attached to this mail is an example. The kernel module represents
> the actual "kernel-bug". Its whole purpose in this example is to
> introduce a user-triggerable NULL pointer dereference.
> Please stop typing now, if you are typing something like
> "If you can load a kernel module, you have access to the kernel anyway".
> This is different. We always _had_ and most likely _have_ NULL pointer
> dereference bugs in the kernel.
>
> The example programm injects a magic value 0xB15B00B2 into the
> kernel, which is printk'ed on success.
>
> In my opinion, this should be forbidden by disallowing mmapping
> to address 0. A NULL pointer dereference is such a common bug, that
> it is worth protecting against.
> Besides that, I currently don't see a valid reason to mmap address 0.
>
> Comments?
>
--
Greetings Michael.
prev parent reply other threads:[~2006-10-06 14:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-05 18:59 Really good idea to allow mmap(0, FIXED)? Michael Buesch
2006-10-05 19:50 ` linux-os (Dick Johnson)
2006-10-06 14:40 ` Michael Buesch
2006-10-05 21:58 ` Alan Cox
2006-10-06 14:44 ` Michael Buesch
2006-10-07 11:23 ` Pavel Machek
2006-10-05 23:55 ` David Wagner
2006-10-06 4:34 ` Jeremy Fitzhardinge
2006-10-06 5:39 ` Jan Engelhardt
2006-10-06 19:47 ` David Wagner
2006-10-06 7:25 ` Arjan van de Ven
2006-10-06 10:36 ` Mikael Pettersson
2006-10-06 11:20 ` Arjan van de Ven
2006-10-06 19:43 ` David Wagner
2006-10-08 0:22 ` Jeremy Fitzhardinge
2006-10-08 2:03 ` David Wagner
2006-10-08 19:18 ` Michael Buesch
2006-10-06 14:55 ` Michael Buesch [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200610061655.32249.mb@bu3sch.de \
--to=mb@bu3sch.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.