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

[deraadt () CVS OPENBSD ORG (Theo de Raadt)]

> 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.

*MANY* sites run imap such that the user has no valid login shell, and I
am quite surprised to hear that you think otherwise.

So, as far as I can see, this is a remote hole.  Attacker gets in, and then
uses some other localhost hole to gain root.

Pretty obvious.

> 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:

Well, to put it extremely lighty, I am UTTERLY SHOCKED by this
attitude.

        "not worth the effort"

It's starting to sounds like some kind of Seattle disease.

> 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");

Unless I've missed something, this code is incorrect.  It will leave
the cwd outside the chroot space, thus permitting anyone to still get
outside.  In almost all cases, a chroot() which is not immediately
followed by a chdir() is a security problem.

> 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?

First off, not all the world is RedHat.

And, even then, how about fixing the software anyways, instead of
relying on a crutch?