ELF ET_REL

For Junk Mail junk_mail at irishbroadband.net
Tue Dec 25 04:14:51 PST 2007


> > > Preventing TEXTREL is logical, but what about preventing ELF ET_REL
> > > injection in kernel memory? The available tools can now evade
> > > PAX/grsecurity and they do this from user space; I find this disturbing.
> >
> > I don't know anything about this, maybe someone else does.

I'm no programmer, but the briefest of google searches reveals much. The
structure of elf files is known; these techniques are effectively able
to rewrite your binaries in a fashion that hackers could use. They could
always be overwritten on disk. Now, I gather, also in memory. Plenty of
tools there. Add elfsh as a search term if they don't jump up at you.

This appears to allow a hacker to develop & test his hack on his own
box, then inject a packet into e.g. the running sendmail binary to alter
it's function for his ends. He doesn't need a pointer to his own code if
he injects it. The md5 of the binary in ram and the binary on disk will
differ, but how do you check that? Who restarts sendmail on a server? (I
suppose the guy who just got fired :-)). And to alter sendmail he
wouldn't have to hack sendmail, just get in somewhere.

I don't know enough about the existing security measures in ram to know
how difficult this is on a hardened or unhardened box, but the stuff
offers "Yeah, yeah we bypass all those hardening  tricks". If I have
understood this correctly, it will take kernel patches to get out of it.
Grsecurity.org has a test patch for 2.6.23 that appears to address it in
some way. 

http://www.grsecurity.org/test/pax-linux-2.6.23-test13.patch

Dec.
-- 
For Junk Mail <junk_mail at irishbroadband.net>




More information about the hlfs-dev mailing list