On Tue, 2007-10-09 at 23:06 -0700, Aaron Stone wrote: > > It's for the edit script mode in dbmail-sievecmd. I needed > to > > know the > > name of the temporary file so that I could pass it as an > > argument to the > > EDITOR command, and none of the more secure temporary file > > variants hand > > back the file name. (Or if I missed one, please clue me > in :-) > > > > Aaron > > > > With the word "dangerous" here, is there any real security issue for > > running dbmail-timsieved? In what situation? > > Here's the possible attack: someone with shell access captures the tmp > file that dbmail-sievecmd makes while you are using it in live edit > mode, then inserts a script that does something unpleasant with mail > for > that one user (discard, redirect, lots of vacations, etc.). > > That's it. I don't see any real world problem.
It's a little more than that. dbmail-sievecmd has to run with "privileges", at least as a user who can read dbmail.conf, and I'd guess it's common to be run by root. This is a local race condition, and when you combine it with another race condition in dbmail-sievecmd, you can overwrite arbitrary files as the user running dbmail-sievecmd; if that user is root, it's a total system compromise, and if running as another user it's at minimum a total dbmail database compromise. Note, that's a double (actually triple) race condition, and probably requires a world-writable current working directory, so the world isn't exactly coming to an end, but maybe worth addressing. The scenario goes: 1. tempnam() is run and finds a filename in /tmp not in use 2. attacker creates that file (mode 666) before fopen() is called (race condition 1) 3. editor is run and exits (file contents may or may not change) 4. attacker overwrites file contents with malicious contents (or hardlinks the filename to a different file of malicious contents) 5. dbmail-sievecmd tries to insert those contents and as it's not a valid sieve script, fails 6. dbmail-sievecmd, with current working directory of /tmp, does it's loop to find an unused dbmail-invalid.xxx.sieve filename 7. between the stat() which finds an unused name and the rename() of tmp to that filename, attacker creates a symlink with the new name pointing to someother file, which gets overwritten (race condition 2) So if running as root, and that other file is /etc/passwd or a variety of others, you have system compromise. If the file is dbmail.conf, you can supply your own password (if you get the host/username/etc. right). Step 4 (which would be the 3rd race condition) could alternately be Simply setting TMPDIR to a non-world-writable directory would foil all this (installation procedure). I believe you could also use mkdir() on the tmp name and put a file under that, as mkdir() is atomic (no race condition). If dbmail requires glibc (unknown), it also has a "x" mode to fopen() which uses O_EXCL, which would also solve the issue. Also on installation procedures, make sure you don't install dbmail-sievecmd with setuid, or it gives the user a text editor running as the dbmail-sievecmd user, with the same implications as above, but no race conditions required. -- Jesse Norell Kentec Communications, Inc. [EMAIL PROTECTED] _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
