response to the bugtraq report of buffer overruns in imapd LIST command

[MRC () CAC WASHINGTON EDU (Mark Crispin)]

The recent BUGTRAQ report about a way to cause the LIST command to get a
buffer overflow was just forwarded to me.

As was indicated, all privileges are dropped at that point.  There is nothing
that can be done by crashing imapd this way that can not also be done (much
easier) by logging in to the UNIX shell.

I strongly recommend *against* removing the dummy driver.  That driver
supports the LIST command (hence the IMAP client's ability to view folders)
for all of imapd.

All imapd security efforts have been focused on eliminating root-level
security holes.  To the best of my knowledge, this has been done.  If you
disagree, I would like very much to see the evidence.

There has not been an equivalent effort to eliminate all possible ways to
induce imapd or the c-client library to crash when it is in a non-root state.
I am not certain that the results would be worth the effort, particularly
since there are alternatives, either one of which is sufficient to neutralize
the problem:

If you have a "closed" system (which is the only type of system where this bug
matters), a much better solution is to insert the following instruction in
routine pw_login() in env_unix.c:
  if (chroot (home ? home : ANONYMOUSHOME)) chroot ("/tmp");

I will support a build-time configuration option to do this in imap-2000.

Another important measure is to use StackGuard.  I am very surprised at the
implication that RedHat doesn't use StackGuard.  Is that really true?