linux-kernel - Re: [patch 0/5] Support for sanitization flag in low-level page allocator

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:	Sat, 30 May 2009 15:54:48 +0200
From:	pageexec@...email.hu
To:	Peter Zijlstra <peterz@...radead.org>
CC:	"Larry H." <research@...reption.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Ingo Molnar <mingo@...e.hu>, Rik van Riel <riel@...hat.com>,
	linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...l.org>,
	linux-mm@...ck.org, Ingo Molnar <mingo@...hat.com>
Subject: Re: [patch 0/5] Support for sanitization flag in low-level page allocator

On 30 May 2009 at 15:21, Peter Zijlstra wrote:

> On Sat, 2009-05-30 at 13:42 +0200, pageexec@...email.hu wrote:
> > > Why waste time on this?
> > 
> > e.g., when userland executes a syscall, it 'can run kernel code'. if that kernel
> > code (note: already exists, isn't provided by the attacker) gives unintended
> > kernel memory back to userland, there is a problem. that problem is addressed
> > in part by early sanitizing of freed data.
> 
> Right, so the whole point is to minimize the impact of actual bugs,
> right?

correct. this approach is the manifestation of a particular philosophy
in computer security where instead of finding all bugs, we minimize or,
at times, eliminate their bad sideeffects. non-executable pages, ASLR,
etc are all about this. see below why.

> So why not focus on fixing those actual bugs? Can we create tools
> to help us find such bugs faster? We use sparse for a lot of static
> checking, we create things like lockdep and kmemcheck to dynamically
> find trouble.
> 
> Can we instead of working around a problem, fix the actual problem?

finding all use-after-free bugs is not possible, as far as i know. the
fundamental problem is that you'd have to find bugs with arbitrary read
sideeffects (which is just as hard a problem as finding bugs with arbitrary
write sideeffects which you'd also have to solve). if you solve these
problems, you'll have solved the most important bug class in computer
security that many decades of academic/industrial/etc research failed at.

since there's no (practical and theoretical) solution in sight for finding
and eliminating such memory handling bugs, we're left with tackling a less
ambitious goal of at least reducing their sideeffects to acceptable levels.

of course there'll be always instances and subclasses of bugs that we can
find by manual or automated inspection, but that only shows that the rest
can only by handled by 'working around the problem'.

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