Robert Connolly robert at linuxfromscratch.org
Tue Dec 25 10:24:32 PST 2007

On Tuesday December 25 2007 07:14:51 am For Junk Mail wrote:
> > > > 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

It sounds like basic unix permissions protects us from this. Only the owner, 
or root, of the file or memory can change it. Other than notification, I 
don't think about what to do after being compromised. It's more productive to 
spend the same time preventing the compromise.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20071225/4501a02f/attachment.sig>

More information about the hlfs-dev mailing list