Re: More ELF Buggery

[pageexec () freemail hu]

[moderator: this is a repost of the first try which does not seem to
have made it to the list.]
[nergal: you are on CC just in case it does not make it on the list.]
--------- cut here ----------
> > strange that Pax documentation wasn't there when necessary??
>       Indeed.
>       It is true that applications recompiled as DT_DYN object are immune 
> to the attacks described in my article. Yet at the time when the article was 
> published, the PaX homepage did not contain neither information on method of 
> producing DT_DYN objects, nor mentioned the importantance of doing so. 

since the first version of the linux patch that had ASLR (address
space layout randomization) it was clearly documented in the kernel
configuration help (around last august). the fact that proper
documentation was not (and is still not) provided apparently did
not prevent other more adventurous users to simply ask for it (and
they got what you could have got yourself had you asked for it).

> Therefore I bet that the large majority of PaX users was vulnerable, which 
> makes the attacks worth publishing.

(un)fortunately the scenario where your attack applies is not the intended
use of ASLR, namely you (ab)used the fact the we had left ASLR enabled
even for ET_EXEC executables. this was meant to serve the simple purpose
of allowing testing ASLR without having to recompile/link everything as
ET_DYN, and not to be used in production as it is (which applies to all of
the patch in fact, there are several subtle issues that one has to take
care of before using it in the wild, look at grsecurity.net for a solution
for that).

>       Additionally, in my opinion, solutions like PaX or other
> nonexecutable hacks are useful iff they do not require recompilation of
> applications.

PaX does more than implementing non-executable pages, and in our opinion
is getting closer to what can actually be done against address space
corruption bugs at all (without writing correct code and/or doing full
runtime bounds checking). you can find a small summary at
http://mail.wirex.com/pipermail/immunix-users/2002-May/000431.html.

also consider the fact that if you recompile your kernel you could rebuild
the userland as well (BSDs, Owl, Sourcemage, Gentoo, etc) at the same
time, so were makefiles equipped with ET_DYN targets, users preferring
this approach would not have anything extra to do to make use of this
feature.

> If one has to recompile, one can as well use bounds-checking
> compiler or other compiler-level solutions, which offer better (though by no
> means complete) protection.

which makes it language/architecture/compiler specific, all of which is
not true for ASLR (and kernel approaches in general). also, compiler level
solutions normally have to be applied to an entire distribution and be
maintained as such, whereas ET_DYN executables can be created as needed
and even moved between systems that have/do not have PaX. and let's not
forget that full runtime bounds checking has its impact on performance as
well - would actually be an interesting test to see how the various
methods perform on real-life systems/loads.

> Not to mention administrator's effort required,

there is nothing that would prevent distributions/authors to provide a
make target for ET_DYN executables and package them along with their
normal counterparts. then there will be exactly 0 administration overhead
in using them. will Owl be the first one to set a good example perhaps? in
the meantime interested readers can take a look at
http://www.grsecurity.net/devel.htm to see how (simply) it's done for bind
and openssh.

> and the problem with closed source binaries.

ET_EXEC files can be randomized as well (contrary to popular belief),
although the initial tests indicate that the performance impact can make
it impractical (at least on IA-32) - has to be tested/decided on a
case-by-case basis, much like the non-exec page feature itself
(architectures having native support for non-executable pages should
suffer much less though).

> Note that the PaX author strongly disagrees here.

the real basis for our disagreement is not so much with your opinion on
whether various approaches should be combined (us) or used alone (you),
but the fact that you stated that "(Un)fortunately, I don't see a way to
fix PaX so that it would be immune to the presented techniques." without
stating the above mentioned condition (ie. "kernel only approaches please
or nothing"), without which your statement is of course not true as you
had admitted it yourself.

>       BTW, could someone test and confirm if there is a problem with
> running a DT_DYN binary by direct invocation of the dynamic linker, that is,
> $ /lib/ld-linux.so.2 /home/nergal/pax/et_dyn/linux/a.out
> In my case, the process loops infinitely after main() has terminated. Tested
> glibc versions: latest debian potato update, Owl current.

as indicated earlier in a private mail, it 'works here', so if you can
provide a binary, we'll take a look at it (unless it happens to
everything, then it must be a problem with your particular
gcc/glibc/whatever combo, you could help us by debugging it and see what
goes wrong).