Silvio wrote: > This shouldn't be confused with nergals article with pax on a partial > randomization of the address space which he desribes in his paper. > Perhaps he missed this part of the Pax documentation which describes > how to randomize the start address etc of other things like plt/got > of the binary being executed etc (I cant remember seeing this in nergals > paper, so I might be confused here)? Some clarification is due, at last. > 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. Therefore I bet that the large majority of PaX users was vulnerable, which makes the attacks worth publishing. Additionally, in my opinion, solutions like PaX or other nonexecutable hacks are useful iff they do not require recompilation of applications. 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. Not to mention administrator's effort required, and the problem with closed source binaries. Note that the PaX author strongly disagrees here. BTW, when writing the article, I was aware of another method of preventing of my attacks. It is enough to recompile a binary with a linker script modified so that the binary is mmapped at the area starting at 0x00110000. Then the PLT addresses contain 0, and can't be usually used as return addresses in a overflow payload. I haven't mentioned this solution as well, as I found it not relevant (because it requires recompilation). Which, again, is my opinion only. 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. Save yourself, Nergal
