Precedence: list
MIME-Version: 1.0
In-Reply-To: <148752.52050.bm@smtp133.mail.ukl.yahoo.com>
References: <CA+T2pCEvey5ztLcjgJAi3aTXLrQz4O3DNiUk5P8C=FVVCGumwg@mail.gmail.com>
	<965117.94628.bm@smtp142.mail.ukl.yahoo.com>
	<CAML-UdtXXNx83NHWu7v8jm2g2mxPpPgvcubezo_VL7BtUuLW5Q@mail.gmail.com>
	<148752.52050.bm@smtp133.mail.ukl.yahoo.com>
Date: Wed, 11 Apr 2012 23:27:00 +0000
Message-ID: <CA+T2pCH751w58S9hXB7CyTWEY1_aD3CV4qiswDT8M9OiUsDZxw@mail.gmail.com>
Subject: Re: [alpine-devel] [announce] Sonnet GNU/Linux (somewhat derivative
 of Alpine)
From: William Pitcock <nenolod@dereferenced.org>
To: Kevin Chadwick <ma1l1ists@yahoo.co.uk>
Cc: alpine-devel@lists.alpinelinux.org
Content-Type: text/plain; charset=ISO-8859-1

Hi,

On Wed, Apr 11, 2012 at 2:18 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> On Wed, 11 Apr 2012 08:24:36 -0400
> Kiyoshi Aman wrote:
>
>> > Any plans for a grsecurity/pax enabled kernel?
>>
>> As I understand it, PaX and grsec are both pretty worthless for
>> security;
>
> As I understand it, PAX and grsec make many known exploits fail. What
> grounds are you arguing this on. The fact mprotect is often disabled?

This is false.  The fact that the distribution is compiled with PIE is
why many known exploits fail.  The fact that binaries are compiled
with PIE allows the ASLR code (either in Linux itself or provided by
PaX) to randomize specific segment addresses in a binary.  ASLR is the
reason why ret2libc attacks are not successful.

Now for a discussion about PaX mprotect.  PaX mprotect contains two
somewhat-related components:

- hardening mprotect() to enforce W^X policy:

This part is actually somewhat useful: it ensures that badly written
programs do not successfully request mprotect(..., PROT_WRITE |
PROT_EXECUTE) by ensuring that PROT_EXECUTE is dropped or forbidden by
mprotect() with errno=EPERM.  However, this part can be easily written
in a way where it is suitable for inclusion in the mainstream kernel
and is very trivial to write.  It also ensures that the stack can
never be PROT_EXECUTE as a side-effect, also useful except in cases of
trampoline, where you have programs with PT_GNU_STACK marking or PaX
equivilant.

However, there is a better approach to handling W^X, which is just to
automatically drop PROT_EXECUTE anytime PROT_WRITE is requested (and
also the reverse).  This provides the same security and is more
compatible with virtual machines like Jaegermonkey, V8 and luajit.
This is the approach as taken by OpenBSD, and coincidentally is
partially implemented in modern Linux kernels.  Some further
protection by default is desirable here, but not really important in
terms of defeating vulnerabilities.

- using the CS register to emulate an NX-bit on legacy x86 platforms:

This part is entirely worthless, defeating the NX-bit emulation is
trivial if you know what you're doing due to the limitations in the
way the CS register works.  To put it simply, the CS register defines
the highest possible address of executable code.  In other words, it
should always be higher than ELF_LOAD_BASE, and should always be the
size of .text.

However, when you need mprotect(..., PROT_EXECUTE) then the CS
register has to be modified to point to the end of your memory mapping
you're marking PROT_EXECUTE.  When *that* happens, everything between
ELF_LOAD_BASE and the end of your PROT_EXECUTE mapping is now
executable, including any mappings that lay before it.  ASLR helps
against this a little, because mmap() mappings are at randomized
addresses, but in reality with the CS segment, the ASLR actually makes
this worse.

Regarding ASLR itself, I suspect PaX ASLR to be actually more weak
than the default Linux ASLR with randomize_va_space=2.  Thusly,
there's not really any benefit to using PaX.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---