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