linux-kernel - Re: [PATCH] Make /proc/slabinfo 0400

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:	Fri, 04 Mar 2011 17:02:36 -0600
From:	Matt Mackall <mpm@...enic.com>
To:	Pekka Enberg <penberg@...nel.org>
Cc:	Dan Rosenberg <drosenberg@...curity.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Theodore Tso <tytso@....edu>, cl@...ux-foundation.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] Make /proc/slabinfo 0400

On Sat, 2011-03-05 at 00:14 +0200, Pekka Enberg wrote:
> On Sat, Mar 5, 2011 at 12:10 AM, Pekka Enberg <penberg@...nel.org> wrote:
> > I can think of four things that will make things harder for the
> > attacker (in the order of least theoretical performance impact):
> >
> >  (1) disable slub merging
> >
> >  (2) pin down random objects in the slab during setup (i.e. don't
> > allow them to be allocated)
> >
> >  (3) randomize the initial freelist
> >
> >  (4) randomize padding between objects in a slab
> >
> > AFAICT, all of them will make brute force attacks using the kernel
> > heap as an attack vector harder but won't prevent them.
> 
> There's also a fifth one:
> 
>   (5) randomize slab page allocation order
> 
> which will make it harder to make sure you have full control over a
> slab and figure out which allocation lands on it.

I think the real issue here is that it's too easy to write code that
copies too many bytes from userspace. Every piece of code writes its own
bound checks on copy_from_user, for instance, and gets it wrong by
hitting signed/unsigned issues, alignment issues, etc. that are on the
very edge of the average C coder's awareness. 

We need functions that are hard to abuse and coding patterns that are
easy to copy, easy to review, and take the tricky bits out of the hands
of driver writers.

I'm not really sure what that looks like yet, but a copy that does its
own bounds-checking seems like a start:

copy_from_user(dst, src, n, limit) # warning when limit is hit
copy_from_user_nw(dst, src, n, limit) # no warning version

-- 
Mathematics is the supreme nostalgia of our time.


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