aaron@pjscom.UUCP (Aaron J. Olivia) (03/24/84)
Having currently taken over the administration of our system, I have a desperate need to find the security hole left by /bin/mail. (We are running Berkeley 4.1). Can anyone shed some light on this problem ? please send replies to ...decvax!ittvax!bunker!pjscom!aaron
george@idis.UUCP (George Rosenberg) (03/26/84)
Security and Integrity Problems with Mail copyright 1984 by George Rosenberg The right to store this on computer or transmit it between computers is explicitly permitted. All other rights are reserved. [This could be a touchy subject. I don't want something published that is taken out of context or unverified.] There has been some recent discussion about security problems with mail. Some articles allude to some of these problems, but avoid describing what they are. The problems are no big secret. Some of them are documented in the UNIX programmer's manual. I don't believe that I have seen them all listed together. This is the beginnings of such a list. Perhaps after some discussion someone can post a more complete and accurate list. This list, for the most part will refer to v7 /bin/mail. It will only be concerned with intra-machine mail. It will not be concerned with rmail. I am not recommending any remedies, although this would be appropriate for such a list. (Of course, one remedy is "cp /dev/null /bin/mail".) Everything here is based on my recall without going to the trouble of consulting sources or making tests. This can be broken into two aspects. One is security and integrity of the mail messages (M). The other is security and integrity of other files (F). As far as I know, none of these problems are the type that would happen accidentally. They are all the type that require one to intentionally exploit it. These are of course much less serious, but they may be of concern in some environments. This also may be why the mail program has not been changed to eliminate the problems. The file problems (F) are all because /bin/mail is setuid root. It is designed to be setuid root. In some cases mail is not careful enough. In other cases the operating system has been changed, and the consequences for mail were ignored. This last point is probably a general problem with setuid and setgid programs and with any programs run by root. 1. F Mail appends to existing mail files. It can be tricked into appending to other files. This directly affects the integrity of files. Since some system security presumes the integrity of certain files (e.g. /etc/passwd), security is indirectly compromised. Some versions of mail could be told to mail to arbitrary files. I do not recall if that is true with v7 mail. The use of links, chroot, and I assume symbolic links can be employed to trick mail into modifying a selected file. I believe that many systems restrict chroot to the super-user. Since hard links can not be made across file systems, it would be best if the mail spool directory were on a different file system than trusted files, so as to avoid also compromising security. Unless chroot is used this requires the ability to write in the mail spool directory. I believe that the mail program was designed assuming that directory is publicly writable. A partial list of files in which compromising their integrity could compromise system security. /unix /etc/passwd /etc/group /usr/lib/crontab /usr/spool/at/* /etc/rc /.profile /bin/* 2. F Mail does a chown of the file in which it puts mail. It can be tricked into changing the owner of other files. Mail will also append something to that file. A. One can become the owner of someone else's file and do what they want with it. One can even change the mode, restore the original owner and clean up the appended garbage. This can also compromise trusted files as discussed previously. B. One can effectively give away files, potentially defeating file space accounting where it exists. C. One can create a file with a desired mode (e.g. 04777) and change the ownership to someone else. On some systems chown will clear the setuid and setgid bits. On many systems it will leave those bits unaffected. I believe that the mail program can be tricked either with methods similar to those discussed in 1. above or by using chroot so that mail consults a bogus password file. 3. M The mail spool directory is writable by anyone. I believe that the mail program was designed assuming that directory is publicly writable. This compromises the integrity of the mail. Anyone can delete that link to your mail file. If it is the last link, the mail is lost. A partial solution is to have another link to the mail file. Of course someone could still delete the link in the spool directory, wait until mail arrives, and then delete the new file. 4. M If a mail file does not exist for a user the mail program will create one when it tries to deliver mail to that user. In such cases the protection of that file (mode) might be controlled by the person sending the mail. Combining this with 2. or 3. above could compromise the security (privacy) of that user's mail. 5. M There is no simple mechanism for authenticating signatures. I believe one could use secretmail with some appropriate protocol to verify a signature (assuming you are willing to believe the user whose signature is being questioned). This is awkward and it isn't part of /bin/mail. 6. I believe that there is no problem with the mail shell escape. George Rosenberg idis!george
henry@utzoo.UUCP (Henry Spencer) (03/30/84)
You are confusing V7 mail with Berkeley's brain-damaged and buggy
modification of it. With the exception of some aspects of the problem
of signature authentication, V7 mail has *none* of the problems you
describe. In particular, it's perfectly happy to run with a spool
directory that is not writeable to everyone.
It would be nice if Berkeley dropped its habit of referring to x.yBSD
(in particular, when x is 2) as "Unix Version 7". This borders on
criminal fraud nowadays, since Berkeley's latest products don't even
look much like Unix any more, much less V7.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrygwyn@brl-vgr.ARPA (Doug Gwyn ) (03/31/84)
Hear, hear. Speaking of fraudulent use of "Version 7", what about "UNIX" which is, as we all know, a trademark of AT&T (or AT&T Bell Laboratories or some such)? x.yBSD may be nifty but more and more I am hearing people saying that it isn't UNIX (especially after the signal botch in 4.2BSD). We want Research Version 8! (At least I *think* we do.)
george@idis.UUCP (George Rosenberg) (04/01/84)
Errata to my article on Security and Integrity Problems with Mail That article contained the following caveat: "Everything here is based on my recall without going to the trouble of consulting sources or making tests." I pointed out that several of the problems I mentioned depended in part upon a writable mail spool directory. (They did not all depend on this.) I said: "I believe that the mail program was designed assuming that directory is publicly writable." Henry Spencer pointed out (utzoo.3691) that regarding this assumption I was confusing v7 /bin/mail with other versions of /bin/mail or other mailers. I believe he was correct about this. Apparently v7 /bin/mail does not make that assumption. In order to correct my article the above sentence (two occurrences) should be changed to: "I believe that mailer programs on some UNIX systems were designed assuming that directory is publicly writable. If you are certain that the mailers on your system do not need that directory to be publicly writable, you might want to protect the directory so that it is not publicly writable." Delete the following sentence from that article. "This list, for the most part will refer to v7 /bin/mail." The below sentences were in the article. "In such cases the protection of that file (mode) might be controlled by the person sending the mail. Combining this with 2. or 3. above could compromise the security (privacy) of that user's mail." Change them to the below sentence. "In such cases the protection of that file (mode) might have some liberal value which could compromise the security (privacy) of that user's mail." George Rosenberg idis!george
kermit@Brl-Tgr.ARPA (04/03/84)
From: Charles Kennedy <kermit@Brl-Tgr.ARPA> Yeah, but I notice that AT&T (or whatever) is putting lots of nice "Berzerkleyisms" back into SysV, Rel2 (like long variable names).