Well, I think you misunderstood the question ;) > Now, I gather, also in memory. Plenty of > tools there. Add elfsh as a search term if they don't jump up at you.
Elfsh does nothing in memory... it patches the original binary, and for sure it can be protected by Grsec acl´s. > > 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. There is some ideas to verify that, but it´s not needed, since to inject code ´in memory´, the user need one of the follow: - Kernel memory access (so, just StMichael can protect you) - Ptrace privileges (so, you are not using a hardened system) Again, what elfsh does, and the motivation for their claim about work in pax enabled environment, are generate a new binary. cya, Rodrigo (BSDaemon). -- http://www.kernelhacking.com/rodrigo Kernel Hacking: If i really know, i can hack GPG KeyID: 1FCEDEA1 --------- Mensagem Original -------- De: Hardened LFS Development List <[email protected]> Para: Hardened LFS Development List <[email protected]> Assunto: ELF ET_REL Data: 25/12/07 08:55 > > > > > > 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. > > > 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 > > > > > ________________________________________________ Message sent using UebiMiau 2.7.2 -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
