[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).
