mailing list archives
Re: More ELF Buggery
From: nergal () 7bulls com (Rafal Wojtczuk)
Date: Fri, 7 Jun 2002 11:53:29 +0000
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??
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.