Re: More ELF Buggery

[nergal () 7bulls com (Rafal Wojtczuk)]

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