[8814] in bugtraq
Re: Postfix design directions
daemon@ATHENA.MIT.EDU (Ewen McNeill)
Thu Dec 24 18:51:30 1998
Date: Thu, 24 Dec 1998 12:25:15 +1230
Reply-To: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Ewen McNeill <ewen@NAOS.CO.NZ>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Your message of "Tue, 22 Dec 1998 15:02:30 CDT."
<19981222200230.6E97245901@spike.porcupine.org>
In message <19981222200230.6E97245901@spike.porcupine.org>, Wietse Venema writes:
>[Postfix world-writeable queue directory; vrs setuid/setgid program]
>[Attack exists against postfix causing lost mail, by hard linking a from
> a file in the mail queue to somewhere else; postfix will remove mail]
>
>file from the queue and the mail is not delivered. In order to stop
>this attack one would have to keep maildrop queue file names secret.
If the directory didn't have read permission (one of your suggested ways
of helping keep the queue file names secret) then the postfix program
which lists the mail in the queue waiting to go out may need to be
changed in order for it to still work (or to be discarded completely).
(I'm assuming there is such a program; I haven't looked at postfix, but
ISTR a comment to this effect either here (Bugtraq) or in something I
read about postfix's design.)
It would probably be possible to limit this functionality to a mail
administration group, give that group read permission, but not the world
read permission. But I'm not yet convinced this is a good idea; on
systems I don't administer I have found it useful in the past to be
able to find out if the mail message I sent is still sitting in the
mail queue, when, eg, mailing something to myself at another account
and wondering why it hasn't turned up.
The other approach is to give this "show me the queue" program more
privilege than the user; ie setuid/setgid.
Besides which making the "queue file names secret" makes the attack
(much) more difficult (give a large enough name space, and enough
randomness in the names), but not impossible. And it means that all
other postfix programs must be careful not to reveal directly or
indirectly the file names.
One potiental problem with this is kernel system call tracing, which
would reveal the file names being used. The only attacks I can
think of on the submit-a-message program require either a world-
writeable directory in the commonly used (executables) search
path (eg, put in another binary of the same name earlier in the path,
run the real program system call traced to a file, delete the mail as
above), or writeable common startup files (eg, an alias), or are attacks
on one's own mail (which isn't very useful, but could I suppose be used
to claim mail was "sent" when it wasn't, depending on the way the log
messages are written). But there may be attacks on other postfix
components which could reveal other queue file names.
>[alternative, setuid/setgid program]
>If a world-writable maildrop directory can be attacked, what about
>set-uid/gid programs? My concern is with the large amount of control
>that an attacker has over a set-uid/gid process. [...]
>why writing a set-uid/gid program requires a great deal of care.
Indeed a lot of care is required. However in some respects I think this
can be mitigated by making the privilege gained by such an attack
as nearly useless as possible.
In this instance a setgid program to write into the mail queue directory
which uses a gid that is used only for writing into that queue
directory. If someone manages to exploit the program they gain the gid
needed to write into that queue directory, which in turn gives them the
ability to perform the attack noted above (ie, cause postfix to delete
without delvering mail).
Writing the setgid program would obviously still require care, but
unlike for instance programs that are setuid root there's not the same
all-or-nothing knife-edge risk to security involved.
It seems to me there's several choices here:
0. Do nothing; leave it the way it is.
1. Make the queue directory write-only to users; no way to see the queue
2. Make the queue directory write-only to users, readable by admins
3. Make the queue directory write-only to users, with setgid program to
read the queue available (potientally) for everyone to run
3a. Make the directory write-only to users, provide another source
of mail in the queue information.
4. Make the queue writable only by a special group, and provide a
setgid program to write into the queue; readable by everyone
5. Make the queue writeable only by a special group/user, and
readable only by a special group/user. Provide a setgid/setuid
program to write into the queue; provide a setgid/setuid program
to read the queue.
Given the ease in which the attack can be performed (create a directory
in the queue directory, hard link into there), I don't think that 0 is
reasonable, at least for use on a public system.
I don't think 1 is reasonable on a busy public system; having to
become root each time to check on mail issues raises the risk of
something else going wrong while root to work on mail issues (running
the wrong thing, trojan binary in the path, etc).
2 is potientally reasonable if one is prepared to remove the ability for
users to find out what is in the mail queue, but as a general user I've
found that a handy ability to have from time to time.
3 is a potiental solution; but with the setgid program there I don't
think it offers much over 4. The list-the-queue program would also have
to be careful not to give away what the names of the files in the queue
directory were (directly or indirectly). (This is probably a big
concern where system call tracing is possible.)
With 3a I thinking of solutions like a log-based system, or perhaps a
server program that can be queried via, say, a unix domain socket as to
what mail is waiting to go out. With a server program running it's got
more privilege than the user, and thus is potientally expolitable
somehow (but would be more difficult). Keeping a log-based system up to
date is potientally more difficult, and possible more inefficient. It'd
have be careful not to give away the queue file names to users; and yet
an admin might need to know the queue file names. Some other name could
identify the mail for admins, but then whatever worked with that other
name could possibly be attacked to find out the file names (eg, system
call tracing).
I think 4 would be the solution I would pick when faced with this issue,
with a group used only for this purpose. I think the
write-into-queue-directory functionality is simplier than the
display-the-queue functionality, and hence less risk of mistakes. It
could potentially also work with a user-front end companinion program
which was not setgid, but did most of the preperation of the message to
go into the queue, and then exec'd the setgid program. Then the setgid
program need only check that it is in the right format, and write it
into the directory, rejecting anything that isn't out-of-hand (rather
than, eg, being nice to users).
Obviously the setgid program would need to be reviewed in the face of
changes, but since this is less of a knife-edge risk to security, I
think this is a less pressing concern than a good solution now.
On its face, solution 5 has some merit. It'd need one special user and one
special group (one that writes, one that reads; the user should not be
in the group). If the user exploits one of the programs and gains that
privilege then they can do one of read the directory or write into the
directory. Unless the exploit both programs (and hence gain both read
and write privilege), or guess the queue file names, they cannot perform
the attack above. However, in addition to the need to write/maintain
two programs with special privilege, the one that lists the queue can be
attacked by system call tracing, and hence only the write privileges are
really needed. I don't think it offers enough over 4 to be worth the
effort.
Ewen
