LD_PRELOAD attack

[David Shaw]

On Wed, Jun 11, 2008 at 10:43:02AM -0400, michael graffam wrote:
> Has anyone read the article in the most recent 2600 regarding using
> LD_PRELOAD to eavesdrop on gnupg?

I read the article.  For those who didn't see it, the basic summary is
that by using LD_PRELOAD to replace various functions (memcpy and
read) underneath a given execution of GPG, you can snoop on what is
going on.

> But what concerns me more (and isn't explicitely covered in the
> article) is the ability to inject false randomness into GPG key
> generation, or even change the plaintext going in.
> 
> I think the advice to statically link a strcmp and getenv into GPG for
> purposes of checking/scrubbing the environment is a good one.

I don't.  The idea of using LD_PRELOAD to play various security games
is not a new one.  It's fun to play around with and handy for
debugging, but it's not a useful attack in the real world.

If the attacker had access to your machine to implement the LD_PRELOAD
attack, there are literally dozens of ways they can similarly steal
whatever data they are trying to steal.  Why do a very complex attack
involving replacing libraries when they could just replace the GPG
binary itself?  Or add a shell script named 'gpg' and put it in your
search path ahead of the real gpg?  Or turn on typescript by default.
Or load a kernel module that changes the meaning of system calls.  Or
replace the rng with one that isn't random.  Or, or, or.

If you don't have control of your computer, you don't have control of
your computer full stop.  Having GPG do some extra checks doesn't
really help, because the attacker can simply arrange for these extra
checks to appear to succeed, or just replace GPG altogether so they
don't run.

If I may torture an analogy here, being worried about someone who has
access to your computer using LD_PRELOAD to attack you is like being
worried that a burglar has a key to your front door... but your front
door isn't locked anyway.

David