mail security and mailing to files/pipes

utzoo!decvax!ucbvax!unix-wizards utzoo!decvax!ucbvax!unix-wizards
Tue Sep 15 13:09:58 AEST 1981


>From wales at UCLA-Security Tue Sep 15 10:51:17 1981
RE:  Steven Bellovin (UNC-Chapel Hill)'s comment about the security
     holes inherent in a mailer (e.g., Berkeley delivermail) which lets
     you mail to pipes or files over a network

Here at UCLA, we are running a locally written mailer (I wrote it) which
allows mailing to pipes or files a` la Berkeley delivermail.  However,
we protect ourselves by allowing people to mail to pipes or files ONLY
via aliases in the public mail alias file.

To give a trivial example, our mail alias file has a line saying:

			nobody: /dev/null

Anyone who mails something to "nobody" will get his mail appended to
/dev/null.  But if our mailer gets a direct request to mail to /dev/null
(i.e., without going through the alias "nobody"), it gets rejected.

This is done by having our "delivermail"-like program examine each of
its arguments for the characters "/" and "|"; any destination argument
containing either of these magic characters is rejected.  This test is
NOT done, however, for the right-hand sides of alias-file lines .  Thus,
a file or program can get mailed to only if its name comes from a RHS
in the alias file.

So even though program execution and file appending by the mailer gets
done as (gasp!) root, we're still safe, because we can control exactly
which files or programs can get mailed to.  (The masses do not have
write access to the alias file, needless to say.)

As for the mail alias file, it is in /usr, and none of the users' home
directories are in the same file system, so we appear to be safe from
people who would try to mail lines to the alias file by linking it to
their own mailbox.  (However, the flurry of recent comments about mail
security have been noted out here, and we can probably tighten things
up still more.)

If Berkeley delivermail suffers from a security flaw in this respect,
they are welcome to try our solution.

-- Rich



More information about the Comp.unix.wizards mailing list