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: <20090603162831.GF6701@oblivion.subreption.com>
Date:	Wed, 3 Jun 2009 09:28:31 -0700
From:	"Larry H." <research@...reption.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	Stephen Smalley <sds@...ho.nsa.gov>,
	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: Re: Security fix for remapping of page 0 (was [PATCH] Change
	ZERO_SIZE_PTR to point at unmapped space)

On 11:41 Wed 03 Jun     , Christoph Lameter wrote:
> On Wed, 3 Jun 2009, Stephen Smalley wrote:
> 
> > > 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.

Christopher, crippling the system is truly not the way to fix this.
There are many legitimate users of private|fixed mappings at 0. In
addition, if you want to go ahead and break POSIX, at least make sure
your patch closes the loophole.

Given these circumstances, are you proposing this over my patch?

Linus already pointed out the main (functional) problem about it. It
seems you are also confusing the issue, albeit already realized it can
be a venue of attack, which is good.

For instance, there are many scenarios in which a fixed mapping can be
used in a non-zero address to abuse kernel flaws... your patch is
useless against those.

Please let me remind you that my original intent was to prevent
kmalloc(0) from leading to potential NULL or offset-from-NULL access
issues, and not deterring NULL pointer deferences in kernel-land which
is a whole different thing (see PaX UDEREF for clues on this).

> >
> > You can already prevent unauthorized processes from mapping low memory
> > via the existing mmap_min_addr setting, configurable via
> > SECURITY_DEFAULT_MMAP_MIN_ADDR or /proc/sys/vm/mmap_min_addr.  Then
> > cap_file_mmap() or selinux_file_mmap() will apply a check when a process
> > attempts to map memory below that address.

If SELinux isn't present, that's not useful. If mmap_min_addr is
enabled, that still won't solve what my original, utterly simple patch
fixes.

The patch provides a no-impact, clean solution to prevent kmalloc(0)
situations from becoming a security hazard. Nothing else.

If you want to solve NULL/ptr deference abuse from userland, you better
start thinking about separating kernel virtual address space from
userland's, with the performance impact that implies. Few architectures
provide this capability without performance hit, and x86 ain't one of
them.

> mmap_min_addr depends on CONFIG_SECURITY which establishes various
> strangely complex "security models".
> 
> The system needs to be secure by default.

Correct, so what was wrong with my patch again? That the original two
line change was written by the PaX team?

Come on chap, It's not like you will lose your bragging rights among
your peers for admitting that I was right. Just this one time. I won't
tell anybody. Promise.

	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/