Subject: Re: imapd on FreeBSD warning message ...

From: Mark Crispin <[email-masked]>
Date: Mon, 22 Oct 2001 17:51:51 -0700 (PDT)

On Tue, 23 Oct 2001 02:48:39 +0200, Anders Nordby wrote:
> Calling software/packages/port
> maintainers non-professionals because they don't share your opinion is,
> well, not really fair in my opinion.

Look at it this way.  Suppose I posted that "The current version of FreeBSD is
INSECURE and YOUR SYSTEM IS AT GREAT RISK" because I heard about a FreeBSD
security bug 3 years ago.  The FreeBSD community would have a legitimate
complaint.

If you make a statement about the security of a software package, you had
better make sure that you have evidence that such statements apply to that
version.

Only religions damn children, grandchildren, and great-grandchildren for the
sins of the fathers.  This type of practice plays into the hands of those who
criticize the open source community.

> * better, more detailed changelog that is updated for every release - is
> it possible?

When I write up change logs for public distribution (as opposed to our
internal RCS logs), I concentrate on what is user-visible.  I don't see much
point in explaining every edit that is made to every file.  Nor do I have the
time to do so.

> * what specific (!) measures have been made to try to prevent that
> imap-uw will likely be vulnerable to buffer overflows and other common
> security flaws?

There is no longer any instance of the type of code that caused the root
compromise security flaws.

All strings that are copied in all c-client routines used by imapd are either
length-limited or length tested or both.

> * regarding the chroot-server option, how can you strongly discourage
> locking down processes in a chroot sandbox?

You can crack root using a daemon running in a chroot-root sandbox if all of
the following conditions are true:
 1) you have write access to the sandbox directory via a shell
 2) at least one setuid-root program is on the same filesystem as the sandbox
    directory and can be hard-linked into the sandbox directory
 3) that setuid-root program uses the filesystem for a security test.  /bin/su
    is a good example.
 4) you identify a means to subvert the daemon, so that it invokes that
    program from the sandbox directory while the daemon is in the sandbox.

The first three are quite commonplace.  Now you know why modern systems
partitition disks so that home directories are on a different filesystem.

The fourth condition is just a minor annoyance on a system which grants its
users shell access...unless that daemon uses a chroot-sandbox.  In that case,
the problem is suddenly promoted to a root-compromise.

That's why chroot-sandboxes aren't used often.  The best way to think of it is
that *any* problem in a chroot daemon is a potential root-compromise problem.

imapd had two root-compromise security bugs in its 10+ year history.  Chroot
servers historically have had many more (just look at ftpd!!).  I put in the
chroot capability because some people wanted it, but it's turned off by
default and is strongly advised against.