tchrist@convex.com (Tom Christiansen) (11/30/90)
I seem to recall that there's a security hole involved with make an alias of "decode" in /usr/lib/aliases to go to "|/usr/bin/uudecode", but I don't recall how it runs. If anyone knows the problem (if one exists), could you please fill me in? thanks, --tom
jik@athena.mit.edu (Jonathan I. Kamens) (12/03/90)
In article <109516@convex.convex.com>, tchrist@convex.com (Tom Christiansen) writes: |> I seem to recall that there's a security hole involved with |> make an alias of "decode" in /usr/lib/aliases to go to |> "|/usr/bin/uudecode", but I don't recall how it runs. If |> anyone knows the problem (if one exists), could you please |> fill me in? (Note for those of you who are going to read this response and then flame me for posting a security hole to the network.... This security hole is well-known. Any vendor that still has it in its default configuration should have all of its officers flayed alive. Any system administrator who has a decode alias in his aliases file without also modifying sendmail to solve the security problems described below has no one to blame by himself (and his vendor, possibly, but see above :-). I don't believe in security by obscurity, especially when the security problem in question is already as well-known as this one is.) Installing an alias such as that in your aliases file will enable anyone to replace any file on your machine with any other file of their choosing. This is because of a combination of two different bugs. The first is that sendmail will run setuid to some specific default UID whenever processing a pipe in an alias. Therefore, the uudecode that is run by the decode alias will be able to write to any directory that the default alias UID can write to. If you're smart, you make that UID something like "daemon," and you make sure that daemon has write access to as few important directories as possible. Keep in mind, however, that it probably is going to have access to things like the printer spool directories. Bad news. The other is that when sendmail gets mail that it thinks was sent from the local host, any pipes in aliases to which that mail is sent will run setuid to the UID FROM WHICH SENDMAIL THINKS THE MAIL CAME. This means that if I want to replace one of jruser's files, I simply send a bogus mail message to "decode" that will make sendmail think it was sent by jruser, and the uudecode will be run as jruser and will be able to replace any file to which jruser has write access. One way to get around these problems is to modify sendmail so that it doesn't do the setuid stuff described in the previous paragraph, and to make sure that the default UID that aliases are run as doesn't have any special privileges anywhere. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710