Rodrigo Rubira Branco (BSDaemon)
rodrigo at kernelhacking.com
Wed Dec 26 03:34:49 PST 2007
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.
Kernel Hacking: If i really know, i can hack
GPG KeyID: 1FCEDEA1
--------- Mensagem Original --------
De: Hardened LFS Development List <hlfs-dev at linuxfromscratch.org>
Para: Hardened LFS Development List <hlfs-dev at linuxfromscratch.org>
Assunto: ELF ET_REL
Data: 25/12/07 08:55
> > > > Preventing TEXTREL is logical, but what about preventing
> > > > injection in kernel memory? The available tools can now
> > > > PAX/grsecurity and they do this from user space; I find
> > >
> > > 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
> 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.
> For Junk Mail <junk_mail at irishbroadband.net>
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page
Message sent using UebiMiau 2.7.2
More information about the hlfs-dev