<<< Date Index >>>     <<< Thread Index >>>

Re: [PATCH] Remove absolute paths from gpg.rc



On Fri, Mar 16, 2007 at 12:40:27AM +0000, Paul Walker wrote:
> > setting, and I also don't think that any person interested in security
> > should run with garbage in $PATH. I would also guess that it's just as
> 
> That's fine, and I would agree, but the person you're dealing with should be
> assumed to be a normal user, not "any person interested in security".

I agree.

> > easy to modify a person's .muttrc as to put a trojan gpg somewhere in
> > their PATH.
> 
> If you can modify someones personal files, the game's already over.

Not so.  At least not necessarily.

Say there's a (purely hypothetical) bug in Mutt which allows an
attacker to cause mutt to download an arbitrary file (perhaps actually
in an application frequently used to aid mutt in viewing mail and/or
attachments, e.g. lynx).  Say the bug allows the creation of the file,
but in no way allows for the execution of code within the file.  Such
bugs have existed.

A compromise has occured here, but the compromise is relatively minor.
However, if the attacker is able to leverage this attack by saving an
executable file in the user's path, now you have real worries.  In
particular, many users have a directory within their home directory
where they keep their own scripts or local versions of programs.
Usually, the user will want to put this in the PATH first, since
they'll generally want their own local versions of programs to be
chosen over whatever else is on the system.  On many Linux
distributions in the past, ~/bin was such a directory, created by
default when a new user was created, and included in the user's PATH
by default (though I'm unsure of the order).

If the attacker is merely able to upload an arbitrary file, this is by
far the best route to go.  He'll have to make guesses about the best
place to put his trojans, but as I just pointed out, that isn't
necessarily hard.  By contrast, if he's only able to upload files, but
not able to examine the existing contents of files, then replacing
someone's muttrc will almost certainly be noticed, by virtue of Mutt's
almost mandatory customization.  It's nearly certain that something
about the config will be changed, and very likely something the user
will notice with very little effort.

If he's able to upload an arbitrary executable to the user's PATH
though, then the game is really over... at least, it is if you can get
him to run that program.  Someone mentioned /bin/ls, but actually
that's a great one to try to replace.  How many Unix users DON'T use
ls?  

IMO, I'd say this makes for a decent argument for enforcing a
hard-coded PATH in mutt for ALL binaries.  The user appears to lose
flexibility, but macros and such can still execute commands using full
paths.  But I think mutt should (if we really care that much about
security, and i for one do) enforce that such paths need be absolute.

A variety of alternatives exist...  For example, Mutt could simply
refuse to execute any program which the user has write access to, or
in a directory in which the user has write access, perhaps unless the
path to the program was specified absolutely.  [A possible exception
could be made for root, since root can write to any file, though any
sane admin will NEVER read e-mail as root.] 

Using a configure option is reasonable, too.  Somebody mentioned a
user who installs a more secure version of gpg in their home directory
(or some such thing)...  If the user can do that, they can just as
easily compile Mutt and specify their own hard-coded path using
configure options.  That example is not a very good argument against
hard-coded paths at all.  Indeed, it's rather hard to come up with a
good one, when you weigh any such arguments against having your system
trashed (or even just your own files).

Another person mentioned installing a distro's package for mutt, and
having it unable to find binaries.  The distro is going to compile it
with options suitable for being consistendt with the rest of the
distro; i.e. the hard-coded path they compile with will be appropriate
to find their distro's packaged gpg binaries.  That doesn't meet your
needs?  Again, compile mutt yourself.  You're obviously doing
something besides installing your distro's GNUPG packages, so clearly
you can handle custom-installing mutt, too.

Any option you choose is better than letting mutt search for binaries
in the path.  Even specifying the path in the muttrc is better.  If
you're concerned about someone modifying the .muttrc, you can have
mutt do an md5sum on .muttrc and all the files it sources at start-up,
and then before exiting do it again and compare.  Alert the user to
when it has changed.

That won't help when the file was modified while the user was not
running Mutt (or not running mutt with the same config), but that's
really not Mutt's problem (i.e. the bug is not in Mutt), and Mutt will
not have any RELIABLE way to detect that; so Mutt, and Mutt's
developers, can't worry about that case.

Make sense?

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.

Attachment: pgpLQkbIMxB9D.pgp
Description: PGP signature