ELF ET_REL

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.



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 <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
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 <junk_mail at irishbroadband.net>
>
> --
> 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




More information about the hlfs-dev mailing list