In message <19981222200230.6E97245901at_private>, 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:26:09 PDT