linux-kernel - Re: 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: <20090603180037.GB18561@oblivion.subreption.com>
Date:	Wed, 3 Jun 2009 11:00:37 -0700
From:	"Larry H." <research@...reption.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Christoph Lameter <cl@...ux-foundation.org>,
	linux-mm@...ck.org, Rik van Riel <riel@...hat.com>,
	linux-kernel@...r.kernel.org, pageexec@...email.hu
Subject: Re: Security fix for remapping of page 0 (was [PATCH] Change
	ZERO_SIZE_PTR to point at unmapped space)

On 10:35 Wed 03 Jun     , Linus Torvalds wrote:
> 
> 
> On Wed, 3 Jun 2009, Alan Cox wrote:
> >
> > One way you could approach this would be to write a security module for
> > non SELINUX users - one that did one thing alone - decide whether the app
> > being run was permitted to map the low 64K perhaps by checking the
> > security label on the file.
> 
> Unnecessary. I really think that 99% of all people are perfectly fine with 
> just the "mmap_min_addr" rule, and no more.
> 
> The rest could just use SElinux or set it to zero. It's not like allowing 
> mmap's at NULL is a huge problem. Sure, it allows a certain kind of attack 
> vector, but it's by no means an easy or common one - you need to already 
> have gotten fairly good local access to take advantage of it.

Are you saying that a kernel exploit can't be leveraged by means of
runtime code injection for example? By exploiting a completely
unprivileged daemon remotely? It's not 1990 anymore. People compromise
your system from memory, disk doesn't get to see the ladies poledancing
your kernel $pc.

Not easy? You should definitely ask the people who wrote those exploits what
kind of difficulty they encountered writing them. It goes like this:

	1) Have kernel flaw which leads to function ptr call from NULL
	or offset from NULL. Or can overwrite one. Or corrupt a kernel
	object. Not challenging.

	2) In your userland process, map NULL. Insert fake structures
	with proper pointers to your shellcode of choice. Not
	challenging.

	3) Run the exploit.

Not common? Compile a list of past reported NULL ptr deference oopses
from the Red Hat bugzilla, kernel bugzilla or the LKML. Check how many
of those could be triggered via normal syscall/unprivileged code paths.

You didn't answer my follow-up to your initial mail arguing the patch
was of no use, where I described a realistic scenario. Does that mean
you agree with it? If not, I would like to hear your opinion.

	Larry

--
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/