Need help with mail security bug

[George Rosenberg]

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