> > > 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 <[EMAIL PROTECTED]> -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
