GnuPG 1.1.90 released
dgc at uchicago.edu
Wed Jul 3 05:15:02 CEST 2002
* On 2002.07.02, in <20020702231940.GF4624 at akamai.com>,
* "David Shaw" <dshaw at jabberwocky.com> wrote:
> --module-path scares me a little as it can be abused in certain cases
> on multiuser systems. For example, say someone sets their module-path
> to include a world-writable directory. All an attacker would need to
> do is to drop a bogus "idea" or other module in there to subvert the
Two things strike me:
1. It's not really gpg's problem. I can set LD_LIBRARY_PATH=/tmp, too.
1b. Even if it is gpg's problem, precedent allows for --expert to
permit it. :)
2. It would still affect only the user who does dumb things with his
--module-path, not the whole system. The administrator/installer could
in options.skel, or something, but I'm not sure how far you want to go
protecting against that kind of mistake. They could leave the bin
directory world-writable, too.
> 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.
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
-D. Fresh fruit enriches everyone. Takes the thirst
ENSA, NSIT out of everyday time. A pure whiff of oxygen,
University of Chicago painting over a monochrome world in primary colors.
dgc at uchicago.edu We all know that. It's why everyone loves fruit.
More information about the Gnupg-devel