Procmail opens $HOME/.procmailrc before dropping setuid permissions

[Chris Siebenmann]

Ubuntu release: Ubuntu 8.04.3 LTS (Hardy)
Package version: 3.22-16ubuntu3

Procmail is installed setuid root and opens the user's
$HOME/.procmailrc before dropping root permissions.
This is both a bug and a security issue, especially since
procmail makes no attempt to not follow symlinks and
so on when doing the open().

(This is a bug because there are situations, such as
NFS-mounted user home directories with restricted
permissions, where opening a file as root will fail but
opening the file as the user will succeed.)

Verification: 'strace -u <user> -- /usr/bin/procmail -t -Y </tmp/sample-mail'
and watch the order that syscalls are done in. (If you want
to see this in the wild as real mail delivery happens, you'll
need to use SystemTap.) My trace says:

[....]
umask(077) = 077
open("/etc/procmailrc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
stat64("/u/ckstst2/.procmailrc", 0xbfc2f0ec) = -1 EACCES (Permission denied)
open("/u/ckstst2/.procmailrc", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied)
setuid32(2315) = 0

[Kees Cook (kees)]

Thanks for this report! As it turns out, this is just procmail attempting to work around the exact issue (strict NFS). If it were to actually open the rc file as root, it would close it and reopen after dropping privileges:

/*
 * if we happen to be still running as root, and the rcfile
 * is mounted on a secure NFS-partition, we might not be able
 * to access it, so check if we can stat it or don't need any
 * sgid privileges, if yes, drop all privs and set uid to
 * the recipient beforehand
 */
static int tryopen(delay_setid,rctype,dowarning)
 const int delay_setid,rctype,dowarning;
{ struct stat stbuf;
  if(!delay_setid&&privileged&& /* if we can setid now and we haven't yet, */
      (privileged==priv_DONTNEED||!stat(buf,&stbuf))) /* and we either don't */
     setids(); /* need the privileges or it's accessible, then setid now */
  if(0>bopen(buf)) /* try opening the rcfile */
   { if(dowarning)
rerr: readerr(buf);
     return 0;
   }
  if(!delay_setid&&privileged) /* if we're not supposed to delay */
   { closerc(); /* and we haven't changed yet, then close it, */
     setids(); /* transmogrify to prevent peeking, */
     if(0>bopen(buf)) /* and try again */
        goto rerr; /* they couldn't read it, so it was bogus */
   }

Note the "closerc()" attempt above.

[Chris Siebenmann (cks)]

Even if procmail closes and reopens the file later as non-root,
there are still two problems here. First, procmail has opened
(and closed) a file with root permissions. There are 'files'
where merely opening (and closing) them have side effects;
for example, pointing $HOME/.procmailrc at a rewindable
tape device, where an open/close will cause the tape to
rewind. I believe that this is a security issue.

Second, manifestly the attempts to work around NFS
issues don't work. If you run procmail with it setuid root,
your users have home directories on NFS, and your
users don't make their homedir and their .procmailrc
readable to the world, procmail's attempt to open
their .procmailrc as root will fail with EACCESS and
it will *not* retry as non-root. This is a plain bug; we
have seen it here (since 8.04 installs procmail as
setuid root).

(I cannot follow the twisting maze of dense procmail
code to see why it is going wrong, but it clearly is; we
have the mis-delivered mail and the strace/SystemTap
traces to show it.)

[Kees Cook (kees)]

Ah, good point about the open() side-effects. I have emailed upstream, so hopefully they can provide some ideas on the best way to handle this.

[Jamie Strandboge (jdstrand)]

@Kees, did you ever hear anything back from upstream?

[Kees Cook (kees)]

Unfortunately not. :(