Re: Exec-Shield vs. PaX

[Ingo Molnar]

On Thu, 6 Nov 2003 [EMAIL PROTECTED] wrote:

> > The test incorrectly assumes that thread stacks are executable. I suspect
> > we both agree that it's desirable to have thread stacks non-executable as
> > well.
> 
> while i agree with you on this one, it is in stark contrast to what you
> said earlier:
> 
> > there's nothing wrong about an executable stack though. It's been part of
> > Linux ever since.

sorry but i really have to say that your logic is flawed. (It's sad to see
when a discussion deteriorates to such a stage and i've decided to stop it
from my side, see more below. [ thousands of debian-devel readers rejoice
:-) ] )

"The test incorrectly assumes that thread stacks are executable" is not
equivalent to "thread stacks are non-executable". And there's no conflict
in what i say above.

all i'm saying is that each and every application has a fair right to
assume an executable stack. _If_ tools find (or developer asserts it, in
the source) that a particular application does _not_ need an executable
stack then it's perfectly fine for the OS to go for it and enable a
non-executable stack!

you should not do this decision for the application/library in one way or
another.

> also, the test does not only demonstrate that thread stacks are
> executable or not, it demonstrates a fundemental design flaw in
> Exec-Shield: whenever an executable region is created in the address
> space, *everything* below that becomes executable as well. [...]

thanks, the cat is finally out of the bag - you admit here that the
incriminating paxtest code is there to demonstrate what you characterise
as a flaw in exec-shield. Note that none of your arguments tries to claim
that any real application indeed does "mprotect(argv)", which is pretty
telling by itself.

As i have explained it a hundred times, this behavior is a well-known
property of exec-shield, and that we've done a quite good job of reducing
this effect. In fact i've put it into my exec-shield announcement:

# Limitations:
# 
#
# also, if the overflow is within the exec-shield itself (e.g. within the
# data section of one of the shared library objects in the ASCII-armor) 
# then the overflow might be possible to exploit.
#
# [...]
# All in one, exec-shield is one barrier against attacks, not blanket 100%
# protection in any way. The most efficient security can be provided by
# installing as many layers as possible.

But you dont have to believe me, you can try it yourself, install an
exec-shield distro and measure the effect of this exec-shield property.

( sorry, but i'm going to stop contributing to this thread. You are
getting increasingly irrational and emotional, there's nothing more i
could add to this thread. I do acknowledge that PaX is more secure, but i
also say that exec-shield is a hell alot of a difference from a stock
distro. You expressed your feelings that exec-shield is insecure in one
area and apparently you conclude that it's thus useless. There's nothing i
can do to change this irrational bad logic of yours. )

Ingo

ps. for those who'd like to get rid of this thread too, put this into
your .procmailrc:

:0:
* ^Subject:.*Exec-Shield vs. PaX
/dev/null

Re: Exec-Shield vs. PaX

[Ingo Molnar]

On Thu, 6 Nov 2003 [EMAIL PROTECTED] wrote:

> > there's nothing wrong about an executable stack though. It's been part of
> > Linux ever since.
> 
> the brk() managed heap has also been executable. yet you break apps that
> assume so (the ominous XFree86 server would also use the brk() managed
> heap if you were to tell malloc() to not use mmap() at all or for 'big'
> areas only, well beyond the default 128k. actually, for 'small' modules
> XFree86 does use the brk() heap).

yes. This is one reason why exec-shield isnt ready for the mainline kernel
(and might never be). Fortunately, executable malloc() assumptions seem to
be much less widespread than the reliance on an executable stack. But you
are right of course, exec-shield breaks the 'Linus rule' too.

Ingo

Re: Exec-Shield vs. PaX

[Ingo Molnar]

On Thu, 6 Nov 2003 [EMAIL PROTECTED] wrote:

> [...] incidentally, if i were to make use of PT_GNU_STACK in PaX, i
> could claim the same - now what was your point of fighting this silly
> issue?

yes, this was precisely my point to discuss this issue. Executability of
the stack is not some divine privilege given to the sacred few,
distributed via matters of public policy determined by the ruler of the
system, it's simply a property of the code written. The system ought to
detect it automatically and not stand in the way. We implemented the code
for this - and the compiler, toolchain and glibc supports it all across.
If PaX makes use of PT_GNU_STACK [just take the binfmt_elf.c bits] then
this portion of PaX will conform to the Linus rule too. This is not some
magic property only attached to exec-shield.

this is i believe the main goal, in the quest to bring security to the
average user. The only way to do that is to concentrate all technology on
making security as automatic and hassle-free as possible.

i hope we've finally settled this issue, right? You might still think of
me in unfavorable terms but i've got to live with that :-)

> by the way, on another look at your patch i noticed the following:
> 
> 1. you added a new parameter to fs/binfmt_elf.c:create_elf_tables()
>but don't make use of it, probably it's not needed at all now.
> 
> 2. in fs/exec.c:setup_arg_pages() you may create an inconsistent state
>between mpnt->vm_page_prot and mpnt->vm_flags, the former should
>be derived from the latter, just like do_mmap_pgoff() does it.

thanks, i'll fix these!

Ingo

Re: Exec-Shield vs. PaX

[Ingo Molnar]

On Thu, 6 Nov 2003 [EMAIL PROTECTED] wrote:

> > actually, unmodified XFree86 works just fine. It will have an executable
> > stack but it will work out of box - so no app was broken.
> 
> false! my unmodified X server (gentoo) dies with the following core
> when trying to run it under [1]:

you need to update your gcc, glibc and binutils chain and change
exec-shield=1 (all the code is available under the GPL) to get a fully
compatible exec-shield solution.

the patches on my site default to exec-shield=2. exec-shield=2 means
blanket non-exec stacks for _every_ binary. You are trying to make a big
fuss about this for no good reason. My patches default to 2 to get wider
testing without having to recompile all of userspace. (but recompiling all
of userspace shouldnt be an issue on your gentoo box.)

> > X does break if you force exec-shield=2, and it did break even with
> > exec-shield=1 in earlier iterations of exec-shield, but that bug has been
> > fixed.
> 
> excerpt from [1]:

> +int exec_shield = 2;

Look at the Fedora Core 1 distribution released yesterday to see the
complete solution - there exec-shield defaults to 1. You need PT_GNU_STACK
markings for all apps to work under exec-shield. It cannot be solved via a
single kernel patch. If exec-shield is to be added to Debian then this
should be done too.

Ingo

Re: Exec-Shield vs. PaX

[Ingo Molnar]

On Wed, 5 Nov 2003 [EMAIL PROTECTED] wrote:

> [...] also, you did break userland yourself as well, otherwise how would
> you explain the patches RedHat made to the XFree86 server?

actually, unmodified XFree86 works just fine. It will have an executable
stack but it will work out of box - so no app was broken. tuxracer works
out of box as well.

X does break if you force exec-shield=2, and it did break even with
exec-shield=1 in earlier iterations of exec-shield, but that bug has been
fixed.

the XFree86 patching you refer to above we did was to enable non-exec
stack. But this was an iterative thing to enhance security, not something
we had to do because X broke due to exec-shield itself.

Ingo

Re: Exec-Shield vs. PaX

[Ingo Molnar]

On Wed, 5 Nov 2003 [EMAIL PROTECTED] wrote:

> > non-executable pages on anything else but i386 is a triviality, as the
> > hardware and the kernel supports it. There's virtually nothing that PaX or
> > exec-shield has to add to enable them - they are there.

You are right that the other architectures you listed need alot of
nontrivial work and PaX did it very nicely. The two architectures that
will likely capture more than 90% of the CPU market in the next 10 years,
ia64 and amd64 both have executable bits in their pte formats. These need
no extra work. My sentence above should be "any of the x86 successors",
instead of "anything else".

[ i accept your points wrt. relative randomization. ]

> [...] randomization serves NO purpose in the grand scheme, it does not
> provide guaranteed protection against the PaX attack model (arbitrary
> read/write access to the address space). [...]

there's another, practical aspect of address-space randomization which i
find to be the most important: to make worms uneconomic in network
bandwidth terms. The most effective worm in recent history was a
single-packet exploit-and-infect attack, with a high likelyhood to infect
a machine via that single packet. If the worm has to guess certain exploit
parameters then the introduction of just one other packet can make or
break the dynamics of worm propagation - let alone the need for 1024 or
32K packets for a single infection. So randomization does have an
important longterm significance.

i agree that it's near worthless against local attacks or directed
attacks. It might help in eventually bringing more attention to the attack
itself but that's not a guarantee.

> > >   second, paxtest had some bugs which Exec-Shield exposed and made
> > >   Exec-Shield appear better than it is. i've fixed them here and
> > >   expect to release 0.9.5 today or so. the results now look like:

> > 
> > ( how fair that you give me a chance to run it ... not. )

i take this back - you did offer it for download. (I was parsing 'today or
so' as 'sometime later' and didnt check your site. I did check it after
sending the mail and discovered the new package. Obviously my points wrt.  
the 'threading change' remain.)

> > you do realise that most of those 'exploit techniques' overlap with some
> > programming concepts, and you think that those concepts are flawed by
> > design and should be eliminated - i dont agree with this characterisation.
> 
> putting words into my mouth or can you actually quote me on that?

i did not intend to put anything in your mouth - this is how i understood
your paragraph below:

>  - apps that by their nature want to generate code runtime (e.g.,
>   java). they're  broken for good which many people noticed by now.
>   that's good, that was my purpose because i wanted to draw
>   attention to the fact that runtime code generation is an
>   important privilege that should be carefully managed (as it
>   happens to be also one of the exploit techniques).

i took the 'they are broken for good' as equivalent to 'concepts flawed by
design', and 'important privilege that should be carefully managed' as a
signal of your belief that the ability to generate code should be
restricted. I do not agree with this direction. The moment you start to
'manage' stuff that you believe is 'broken for good' it ends up being less
accessible to people.

(let me know if you think this is an unfair/inaccurate characterisation of
your words.)

> what i'm saying is that there are programming techniques (runtime code
> generation in this case) that should be handled more carefully than they
> have been. what PaX does by default FOR NOW is the result of me being
> cautious (and i have not heard of a single PaX user yet who did not
> appreciate it) and not having the resources to fix up userland all by
> myself. [...]

my experience is that resources that get 'managed' manually tend to be
much less accessible to the average user. Scripting (which is a form of
code generation) and generally writing code is the heart of Linux.

I would like to see all these security technologies to show up on Joe
Average's desktop, so government-style manual need-to-know access control
just doesnt cut it. It might work if packaged very very carefully with
lots of care towards making it simple, but i see zero efforts in that
direction. In fact i got flamed for even mentioning PT_GNU_STACK which i
believe is one careful step in that direction.

> you said a lot about what you don't agree with in PaX, what exactly
> prevented you from changing it *yourself*? what prevents *you* from
> disabling MPROTECT by default for example?

we did take a look at the PAX_SEGMEXEC portion of PaX for Fedora (you did
seem to be a reasonable person with tons of experience and this matters
alot when considering patches) and the killer at that time was the 1.5 GB
VM limitation on x86. Exec-shield, as coarse as it might be, does here and
today offer 

Re: Exec-Shield vs. PaX

[Ingo Molnar]

On Wed, 5 Nov 2003, Peter Busser wrote:

> It is in fact a simulation of a multithreaded application. [...]

The test incorrectly assumes that thread stacks are executable. I suspect
we both agree that it's desirable to have thread stacks non-executable as
well.

> I objected to adding tests that include a multi- threaded library,
> because the library might interfere with the results of the test.

in fact it's desirable to properly have the same 'effect' a pthread
library has - after all that 'effect' might have security relevance. The
best way to do that is to use the threading library used by virtually all 
applications on the box where the test is running: -lpthread.

> [...] Feel free to submit tests yourself, I'll add any sensible test.

yep, proper threaded test added. This should put this episode to rest.

Ingo

diff -rNu paxtest-0.9.5/body.c paxtest-0.9.5/body.c
--- paxtest-0.9.5/body.c
+++ paxtest-0.9.5/body.c
@@ -13,6 +13,13 @@
 #include 
 #include 
 #include 
+#include 
+
+static void *test_thread(void *p)
+{
+pause();
+return NULL;
+}
 
 #ifndef PAGESIZE
 #define PAGESIZE   (4096)
@@ -29,8 +36,13 @@
fflush( stdout );
 
if( fork() == 0 ) {
-   do_mprotect((unsigned long)argv & ~4095U, 4096, 
PROT_READ|PROT_WRITE|PROT_EXEC);
+   pthread_t thread;
+
+   pthread_create(&thread, NULL, test_thread, NULL);
+
doit();
+
+   pthread_kill(&thread, SIGTERM);
} else {
wait( &status );
if( WIFEXITED(status) == 0 ) {
diff -rNu paxtest-0.9.5/Makefile.generic paxtest-0.9.5/Makefile.generic
--- paxtest-0.9.5/Makefile.generic
+++ paxtest-0.9.5/Makefile.generic
@@ -2,7 +2,7 @@
 
 CC=gcc
 CFLAGS=-O2
-LDFLAGS=
+LDFLAGS=-lpthread
 ifndef RUNDIR
 RUNDIR=.
 endif

Re: Exec-Shield vs. PaX

[Ingo Molnar]

On Wed, 5 Nov 2003 [EMAIL PROTECTED] wrote:

> > >  glibc creates executable thread stacks by default. [...]
> > 
> > to the contrary, glibc does this:
> > [snip]
> >  $ rpm -q glibc
> >  glibc-2.3.2-101
> 
> that's what RedHat's glibc does. [...]

yes. The changes are in mainline glibc, everyone will pick those changes
up with time.

Ingo

Re: Exec-Shield vs. PaX

[Ingo Molnar]

On Wed, 5 Nov 2003 [EMAIL PROTECTED] wrote:

> > i downloaded the new 0.9.5 paxtest package and amongst other changes it
> > has the following oneliner change:
[...]
> > +   do_mprotect((unsigned long)argv & ~4095U, 4096, 
> > PROT_READ|PROT_WRITE|PROT_EXEC);

>first of all, it's multithreaded. [...]

paxtest does not link to libpthread, nor does it create threads, at all.
How can you claim it's multithreaded?

>  glibc creates executable thread stacks by default. [...]

to the contrary, glibc does this:

 00594000-005a1000 r-xp  09:00 735400 /lib/tls/libpthread-0.60.so
 005a1000-005a2000 rw-p c000 09:00 735400 /lib/tls/libpthread-0.60.so
 005a2000-005a4000 rw-p  00:00 0
 0063b000-0065 r-xp  09:00 730361 /lib/ld-2.3.2.so
 0065-00651000 rw-p 00015000 09:00 730361 /lib/ld-2.3.2.so
 00e25000-00f58000 r-xp  09:00 735396 /lib/tls/libc-2.3.2.so
 00f58000-00f5b000 rw-p 00132000 09:00 735396 /lib/tls/libc-2.3.2.so
 00f5b000-00f5e000 rw-p  00:00 0
 08048000-08049000 r-xp  09:02 5226629/tmp/test
 08049000-0804a000 rw-p  09:02 5226629/tmp/test
 09e9c000-09ebd000 rw-p  00:00 0
 beba6000-beba7000 ---p  00:00 0  <== thread stack guard page
 beba7000-bf5a8000 rw-p 1000 00:00 0  <== non-exec thread stack
 bf5be000-bf5bf000 rw-p  00:00 0
 bfe79000-c000 rw-p fff5d000 00:00 0

 $ rpm -q glibc
 glibc-2.3.2-101

Ingo

Re: Exec-Shield vs. PaX

[Ingo Molnar]

On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:

>   second, paxtest had some bugs which Exec-Shield exposed and made
>   Exec-Shield appear better than it is. i've fixed them here and
>   expect to release 0.9.5 today or so. the results now look like:

i downloaded the new 0.9.5 paxtest package and amongst other changes it
has the following oneliner change:

--- paxtest-0.9.4/body.c
+++ paxtest-0.9.5/body.c
@@ -29,6 +29,7 @@
fflush( stdout );
 
if( fork() == 0 ) {
+   do_mprotect((unsigned long)argv & ~4095U, 4096, 
PROT_READ|PROT_WRITE|PROT_EXEC);
doit();
} else {
wait( &status );

this intentionally calls mprotect(PROT_EXEC) for the highest possible
address one can think of. This call has no useful purpose at all. In other
words, this is a specific, underhand cheat to trigger 'Vulnerable'
messages for all items when running paxtest on exec-shield kernels.  
Bravo!

frankly, i've never experienced anything like this in my many years in the
Linux world. You so far gave the impression of a reasonable and balanced
person but this is as low as it gets. Shame on you.

here are the paxtest-0.9.5 results with that single purpose-less line
removed, for the categories that matter to me:

 Executable anonymous mapping : Killed
 Executable bss   : Killed
 Executable data  : Killed
 Executable heap  : Killed
 Executable stack : Killed
 Anonymous mapping randomisation test : 8 bits (guessed)
 Heap randomisation test (ET_EXEC): 13 bits (guessed)
 Heap randomisation test (ET_DYN) : 13 bits (guessed)
 Main executable randomisation (ET_EXEC)  : No randomisation
 Main executable randomisation (ET_DYN)   : 12 bits (guessed)
 Shared library randomisation test: 12 bits (guessed)
 Stack randomisation test (SEGMEXEC)  : 17 bits (guessed)
 Stack randomisation test (PAGEEXEC)  : 17 bits (guessed)
 Executable shared library bss: Vulnerable
 Executable shared library data   : Vulnerable

Ingo

Re: Exec-Shield vs. PaX

[Ingo Molnar]

On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:

> since a few points have been made regarding $subject, let me clear
> up a few of them:
> 
> 1. 'It seems that exec-shield does 99% of what PaX does'

this is not the case and i'm not claiming it. If you feel attacked, please
dont - i'll stipulate that PaX gives better security than exec-shield, ok?

>   i don't know the origin of that number above, for now i'll just
>   stick to the facts i know:
> 
>   - PaX implements perfect non-executable pages on amd64, i386,
> ia64, parisc, ppc, sparc and sparc64 whereas Exec-Shield has
> some imitation of it only on i386 (it's not true per-page).

non-executable pages on anything else but i386 is a triviality, as the
hardware and the kernel supports it. There's virtually nothing that PaX or
exec-shield has to add to enable them - they are there. [there's the minor
issue of the process stack's protection bits.]

>   - PaX implements best-effort randomization of the entire
> address space, Exec-Shield does it too but at a higher
> code complexity and a lower entropy rate while having
> a worse effect on the kernel entropy pool.

lets also point out that exec-shield offers relative randomization of DSOs
to each other, while PaX only randomizes a single base of the DSOs, their
relative addresses remain constant. This way the randomization bits of
exec-shield add up for brute-force attacks. Lets add it that if a limited
exploit can be turned into an information leak then relative randomization
does not help - but it does help if the first exploit itself needs precise
addresses from multiple DSOs. (I agree that exec-shield drains the entropy
pool more, i've got this on my TODO.)

>   second, paxtest had some bugs which Exec-Shield exposed and made
>   Exec-Shield appear better than it is. i've fixed them here and
>   expect to release 0.9.5 today or so. the results now look like:

( how fair that you give me a chance to run it ... not. )

> 3. MPROTECT is bogus
> 
>   it is not. Ingo says so because he did not understand how
>   PaX works. [...]

[ ... to 100% prevent: ]

>   (1) introduce/execute arbitrary code
>   (2) execute existing code out of original program order
>   (3) execute existing code in original program order with arbitrary data

no. No offense meant, but i say so because right now i dont see the way to
have a generic and usable Linux system with all the restrictions you are
talking about. If you complete your project and everything works and it's
still the same live, flexible and kicking Linux system that we all know
and love then i was clearly wrong. Right now it seems to be heading more
in the direction of a prison - but this is just my judgement. In any case,
i did not want to add any of that to exec-shield. I'll leave the prison
guard work to selinux.

you do realise that most of those 'exploit techniques' overlap with some
programming concepts, and you think that those concepts are flawed by
design and should be eliminated - i dont agree with this characterisation.

denying executability of non-executable memory is a fair game - well
specified and a clear-cut goal. Restricting an OS to do what is arguably a
fair thing to do in a number of cases did not sound so clear-cut to me -
end of story. You might still be right in the long run, but it wasnt
obviously right at first sight, and was not complete either so it had
limited value at this stage.

> 4. PaX breaks apps, specs, whatnot

>   - apps that by their nature want to generate code runtime (e.g.,
> java). they're  broken for good which many people noticed by now.
> that's good, that was my purpose because i wanted to draw
> attention to the fact that runtime code generation is an
> important privilege that should be carefully managed (as it
> happens to be also one of the exploit techniques). [...]

i think here we are in a fundamental disagreement. To take it to the
extreme, being able to 'generate code' [ie. allow an application to write
code, etc.] is one of the fundamental properties of any Linux user
account, and hopefully remains so in the future. If you take that
'privilege' away you'll take away what drives Linux forward - a constantly
growing pool of programmers. I dont want good security to rely on the
system's insistence to remove the ability to generate code from as many
codepaths as possible. There's got to be another way to secure those damn
apps ... the price you are willing to pay is i believe way too high.

i find your approach interesting nevertheless, and i wish you good luck in
bringing it to completion.

>   about PaX breaking specs: i urge Ingo and others saying this to
>   point me to the precise location in SUSv3 or POSIX 1003.1-2001
>   that PaX conflicts with. [...]

many areas of PaX conflict with one of the most basic rule of Linux:

   http://lwn.net/Articles/32980/

[ that i was part of that discussion is only an annoying accident, ending
  up in an API/ABI discussion again wa

Re: Grsec/PaX and Exec-shield

[Ingo Molnar]

On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:

> [...] Exec-shield "can" stop, but "will" stop is a completely different
> matter. I'll let the bugfixed paxtest tell this story, however.

i am 100% sure that by taking the range-property of exec-shield into
account you can construct 'bugfixed' mapping scenarios where exec-shield
will be 'Vulnerable' for each test you can construct. If you do that you
might as well rename 'pax-test' to 'pax-is-best' ;-)

my argument is that for common apps here and now running on my system the
layout is good enough for exec-shield to be quite close to that of PaX.
(It wont be as complete as PaX though, notably the library bss/data areas
wont be protected.)

Ingo

Re: Grsec/PaX and Exec-shield

[Ingo Molnar]

On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:

> [...] the main point of my argument: exec-shield=2 means enabling
> exec-shield on all binaries but the ones it is disabled for.  This would
> be a secure-by-default design, and yet it's being recommended for
> "testing purposes" only?  [...]

yes. It's a compatible opt-in for something that cannot be enabled for all
binaries, instead of an opt-out. You say it's a bug, i say it's a feature.  
A really bad analogy: it's like spam, you want to opt-in not opt-out ;)

> [...] Note that PaX enables itself on all binaries by default, and that
> Ingo here does not argue that exec-shield=2 could result in a
> non-working system.  Basically, his following argument, which I cannot
> refute, is that if exec-shield is DISABLED BY DEFAULT ON ALL BINARIES,
> then it results in a working system.

my main argument is that on a PT_GNU_STACK-recompiled system, you'll see
that the overwhelming majority of binaries and libraries have a non-exec
stack almost straight away. With some extra tweaking and patching it's up
to 99.9%.

[ or you can manually force on the feature for every binary, if you dont
have a PT_GNU_STACK system, via exec-shield=2, and disable exec-shield on
a per binary basis, if you want/need to. ]

i'm not sure why you are fighting the PT_GNU_STACK concept - it's not
connected to exec-shield at all - just take the ELF loader bits from the
exec-shield patch and use it in PaX - it will be for the better to get rid
of a fair share of chpax use. (Like you changed the library layout in PaX
to match that of exec-shield.)

if you could get rid of the 1.5 GB VM limitation of PaX and if you could
change it to use PT_GNU_STACK to set the process stack's protection bits
then i think there's no need for exec-shield - PaX will provide better
protection at no cost and no tradeoffs. I did and still do exec-shield to
solve a problem. If something else does it better with no tradeoffs then
all the better, one less maintainance headache :-)

> Now, I remember some complaining about having to chpax java if you run
> it and PaX breaks it.  How is that more work than running exec-shield in
> =1 mode, and having to explicitly enable it on all binaries you think
> should have protection, since you don't recommend =2 for production
> machines?

you dont have to explicitly enable it on all binaries you think should
have protection - the compiler will do this just fine via PT_GNU_STACK. It
is a property of the binary, not some policy question, whether an
application needs an executable stack or not.

where does PaX re-enable stack executability if an application dlopen()s a
library that needs an executable stack - because eg. it is using gcc
trampolines? Can you enable PaX for Mozilla and guarantee that no plugin
will ever need an executable stack?

java (or any other non-PT_GNU_STACK third party app) will just default to
exec-shield-off.

> Viewing the process' maps file isn't going to tell you what kind of
> protection the process currently has. [...]

the maps file will precisely tell you what kind of protection the process
currently has - take the highest executable address. I've got a script
with which you can continuously monitor the protection status of various
apps on the system. Offenders are taken care of :-)

> [...] How about if someone mprotects a page of the stack rwx?  Whoops,
> entire address space because executable.

yes. No app currently running on my box does this though.

this is one fundamental difference in the approach: instead of breaking
apps and then chpax-ing them, exec-shield lets apps tell that they are
capable of a non-exec stack.

>  From your announcement:
> 
> To provide as good protection as possible, there's no trampoline
> workaround in the exec-shield code - ie. exec-limit violations in the
> trampoline case are never let through. Applications that need to rely on
> gcc trampolines will have to use the per-binary ELF flag to make the
> stack executable again.

this is an old announcement, and says other things too that are not the
case anymore. E.g. this area got reworked since then and these (rare but
existing) apps/libs are detected automatically via the PT_GNU_STACK
mechanism.

it's very easy to list the app executability requirements and the current
protections in a live system, and it's easy to improve them one by one -
while still having a 100% working system.

> [...] (funny how it was never mentioned that PaX is a true per-page
> implementation, while yours is much more coarse grained...that sounds
> pretty substantial too).

under the exec-shield VM layout the only real relevance this has is on
library bss/data executability, for like 99% (or more) of the apps. But
yes, page granularity execution bits are a plus and are available on the
platforms of the future. It was not acceptable to limit the VM to 1.5GB on
x86. It's a tradeoff.

really, if you think granularity is a big issue for everything else but
library bss/data then feel free to ins

Re: Grsec/PaX and Exec-shield

[Ingo Molnar]

On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:

> [...] Are you so certain that Exec-shield stops execution in shared
> library bss/data? [...]

no, it doesnt, this is the main (and pretty much only) substantial
difference between exec-shield and PaX. Exec-shield will stop execution in
ET_EXEC binary's bss/data but it will not stop code injection into library
bss/data. Here is the 'protection matrix' of all the overflowable and
shellcodable virtual memory areas:

stock exec-shield PaX
  ---
  environment/argv/aux  noyes yes
  stack noyes yes
  anon mmapsnoyes yes
  malloc()  noyes yes
  binary bss/data   noyes yes
  lib bss/data  nono  yes

> [...] So I wonder what happens when someone tries to run tuxracer on a
> system that doesn't use PT_GNU_STACK?  Will Exec-shield then break
> "binary compatibility" without the presence of its self-made "standard"?

what do you mean? tuxracer runs just fine here.

If you mean exec-shield=2 then it is 'forcing' exec-shield and is only
recommended for testing purposes. Running exec-shield=1 on a system with
or without PT_GNU_STACK sections will result in a working system.  
PT_GNU_STACK itself influences nothing. Note that the Fedora kernel
defaults to exec-shield=1.

PT_GNU_STACK is a way to _automatically_ tag binaries/libraries whether
they need the stack to be executable or not. So instead of putting the
burden of 'chpax-ing broken applications' on the administrator or
distribution maker (and third party developers, and the scientific
community, and ...), this method tracks executability requirements
automatically. So you'll get a non-executable stack in like 99% of the
cases. It would be great if Debian adopted the PT_GNU_STACK changes too,
they can push the concept of non-executable stacks into the mainstream.

Ingo

Re: Grsec/PaX and Exec-shield

[Ingo Molnar]

On Tue, 4 Nov 2003, Peter Busser wrote:

> > the reply below is mostly a re-send of a mail i sent to you privately 
> > but you repeat this argument again without any apparent answer to my
> > counter-arguments.
> 
> I already suggested you to reread the PaX documentation, there are the
> answers to your questions. There is no need to copy/paste it here.

yes, i've read them, and they do not answer my questions. The PaX
documentation says:

  Non-executable pages and mprotect() restrictions are effective
  in preventing the introduction of new executable code into an
  attacked task's address space.  There remain only two venues
  for this kind of attack:

  [ write files ] [ map existing library ]

this is plainly not true. Firstly, PaX doesnt solve the "write a file and
mmap() it" problem, so what's your point? Secondly, you can eg. write a
shell-script into non-executable memory and system() it. Etc., etc.

The ability to mprotect() a page already requires good control over the
binary, at which point you can do basically whatever the application can
do normally.

Arguing for this mprotect() restriction is like arguing that "i am only a
little bit pregnant". The attacker controls the application and there are
many ways to use that control to do Bad Stuff. The mprotect() restriction
is an after-the-fact restriction that reduces system utility in a way that
by its own documentation is an admittedly non-complete protection. In fact
it adds little if any protection.

Exec-shield does not include such arbitrary policy decisions. The attacker
has broken in, he controls the app, it's just a matter of time until he
owns everything the app owns (or more) - mprotect() restrictions or not.

besides, the mprotect() change:

 Restrict mprotect()
 CONFIG_PAX_MPROTECT
   Enabling this option will prevent programs from
- changing the executable status of memory pages that were
  not originally created as executable,
- making read-only executable pages writable again,
- creating executable pages from anonymous memory.

breaks a fair number of legitimate applications, breaking binary
compatibility, which is an additional no-no too.

and this is easy. Breaking binaries and increasing security by making the
system less useful.

> > Summary: i can see no significant differences between the paxtest output -
> > all the differences seem to be bogus, see the details below.
> 
> Fact is: There is a difference in paxtest output between PaX and
> exec-shield. And it is not a difference in exec-shield's advantage.

this what i'm disputing, because those tests i criticised are arbitrary
(see above). The other tests are OK and paxtest is a useful utility, no
doubt about that!

by your argument you could add this to paxtest:

printf("PaX is inherently better\n");

there's no way exec-shield could get around this "difference in output"  
;-)

> Another fact: If you don't like this difference, you can change the PaX
> kernel configuration to lower the level of security to the same level as
> exec-shield.

my point is that CONFIG_PAX_MPROTECT is not acceptable in a generic Linux
kernel, and that there's no 'reduction in security' by not using it.  If
you can give me specific examples of exploit techniques that this disables
in a way that cannot be worked around then my point is incorrect.

Ingo

Re: Grsec/PaX and Exec-shield

[Ingo Molnar]

On Tue, 4 Nov 2003, Peter Busser wrote:

>   - Running paxtest shows the differences between PaX and exec-shield.
> Everyone is invited to run paxtest to see for yourself.

the reply below mostly a re-sent of a mail i sent to you privately - but
you repeat this argument again without any apparent answer to my
counter-arguments.

Summary: i can see no significant differences between the paxtest output -
all the differences seem to be bogus, see the details below.

Here's the output of paxtest-0.9.4 under an exec-shield-G4 kernel:

 Executable anonymous mapping : Killed
 Executable bss   : Killed
 Executable data  : Killed
 Executable heap  : Killed
 Executable stack : Killed

the above ones are important, exec-shield catches these exploit
categories.

 Executable anonymous mapping (mprotect)  : Vulnerable
 Executable bss (mprotect): Vulnerable
 Executable data (mprotect)   : Vulnerable
 Executable heap (mprotect)   : Vulnerable
 Executable shared library bss (mprotect) : Vulnerable
 Executable shared library data (mprotect): Vulnerable
 Executable stack (mprotect)  : Vulnerable

i do believe the above checks are bogus, please explain to me why this
case is important to handle.

the test checks whether it's possible to execute an area after
mprotect(PROT_EXEC) has been called over it. The answer: of course it's
executable, the application asked the kernel for this!

Any exploit that can call mprotect() has free reign anyway. The ability to
execute a library call or a system-call is End Of Story. Why is it such a
big issue to inhibit mprotect() calls? Especially since not honoring
mprotect() calls breaks existing apps and specifications.

if you can call mprotect() then you can very well call munmap() and
mmap(MAP_FIXED,PROT_EXEC) as well, which is equivalent to the mprotect()
call. From whatever angle i look at this test, it's bogus.

in any case, the above restriction is trivial to add to the kernel but
still i didnt want to add it because it's simply pointless.

 Anonymous mapping randomisation test : 8 bits (guessed)
 Heap randomisation test (ET_EXEC): 14 bits (guessed)
 Heap randomisation test (ET_DYN) : 13 bits (guessed)
 Main executable randomisation (ET_EXEC)  : No randomisation
 Main executable randomisation (ET_DYN)   : 12 bits (guessed)
 Shared library randomisation test: 12 bits (guessed)
 Stack randomisation test (SEGMEXEC)  : 17 bits (guessed)
 Stack randomisation test (PAGEEXEC)  : 17 bits (guessed)

these are acceptable levels or randomization against remote attacks,
except the ET_EXEC one, but ET_DYN is used for PIE binaries so this is not
an issue.

 Return to function (strcpy)  : Vulnerable
 Return to function (strcpy, RANDEXEC): Vulnerable
 Return to function (memcpy)  : Vulnerable
 Return to function (memcpy, RANDEXEC): Vulnerable

(these can only be caught via compiler changes, clearly not a target for
PaX or exec-shield.)

 Executable shared library bss: Killed
 Executable shared library data   : Killed

these are caught by exec-shield too, and are quite important categories to
catch.

 Writable text segments   : Vulnerable

again, i think this is a bogus restriction too. Why deny writable text
segments? Control over the application at such a level is Game Over in
virtually every case.

summary: exec-shield catches all the non-bogus categories and tries to
raise the bar of exploitation, without breaking binary compatibility
arbitrarily.

Ingo