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: <20090603183939.GC18561@oblivion.subreption.com>
Date:	Wed, 3 Jun 2009 11:39:39 -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 11:12 Wed 03 Jun     , Linus Torvalds wrote:
> 
> 
> On Wed, 3 Jun 2009, Larry H. wrote:
> > 
> > Are you saying that a kernel exploit can't be leveraged by means of
> > runtime code injection for example?
> 
> No. I'm sayng that sane people don't get hung up about every little 
> possibility.

Nothing of what has been mentioned is a little possibility. Far from it.

> Why are security people always so damn black-and-white? In most other 
> areas, such people are called "crazy" or "stupid", but the security people 
> seem to call them "normal".

Security people? I honestly share some of the opinions on the industry
that you might have, and I'm likely taking a gamble stating this
publicly.  You are right, there are bleeding imbeciles there. I'm not
part of that 'security people', and will never consider me one. My
interest on security, long time ago, started at the defensive side. I've
been doing kernel development for almost 5 years focusing on
developing _solutions_, not problems. Understanding the offensive side
in depth is a necessity if you want to be realistic on the defensive
one.

If I can help you understand it, and other kernel developers, to come to
a point where realistic, effective security improvements are deployed in
the kernel, we will have accomplished the one and only goal I had when I
started talking to riel or proposing patches.

> 
> The fact, the NULL pointer attack is neither easy nor common. It's 
> perfectly reasonable to say "we'll allow mmap at virtual address zero".

And how could you calibrate if this attack venue isn't easy to take
advantage of? Or not commonly abused? What empirical results led you to this
conclusion?

> Disallowing NULL pointer mmap's is one small tool in your toolchest, and 
> not at all all-consumingly important or fundamental. It's just one more 
> detail.

Definitely, another layer, part of a complex set of measures to deter
different kinds of flaws from all feasible sides. Fundamental to avoid
the situation it is designed to prevent. In the same way as changing
some pointers in the kernel for preventing unwise values to be used when
returning from 'unusual' code paths (kmalloc(0) for example).

> Get over it. Don't expect everybody to be as extremist as you apparently 
> are.

Extremism is the new buzzword. What's next? I'm not the one following up
with dogmatic responses lacking any reasoning. I've supported my claims
every time I expressed them so far. And when I was mistaken or agreed
with a different opinion, I made it clear as well.

Sorry, Linus, but you are taking a long shot calling people names.

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ