Re: Grsec/PaX and Exec-shield
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
Reply to: