> -----Original Message-----
> From: dalek [mailto:wvdtype01.com]
> Sent: Thursday, February 28, 2002 9:09 AM
> To: secprogsecurityfocus.com
> Subject: designing a secure mail server?
>
> I have been thinking long and hard about the design of a secure MTA,
> preferably one that does SMTP and local (to the spool) as well as
> remote (SMTP) delivery.

Sendmail supports TLS between MTAs. I don't believe doing TLS to the
local delivery agent (i.e. LMTP) would be hard to achieve.

> Now please, I know all about qmail and I am using it at a site I admin,
> I am not looking for suggestions on what to use, what I am looking for
> are some links and papers that deal with things like safely binding to
> a high port (25) and dropping privileges,

Sendmail 8.12.x does that. It's no longer installed setuid by default.
The daemon has to start as root because there's no other way to bind to
port 25, but user instances and forked children all run as "smmsp" or
whatever user is designated. The binary is installed setgid to "smmsp",
which is the group of the queue directory to which clients can write.
Users can't get root through the binary from the command line, at all,
ever (unless you know a way to elevate privileges without setuid).

> safe email address parsing so as to exclude characters which might be
> used to redirect the mail or even launch programs on the machine running
> the MTA, etc...

This is a hard problem to solve, because arguably unsafe characters are
perfectly valid according to the RFCs. However, plenty of work has been
done to enforce such things, like "smrsh".

Address parsing isn't the right approach, in my opinion. When you
construct the argv of something the MTA wants to execute, as little as
possible of the format of the command should be user-provided. The MTA
should control the path of the binary being executed and all of the
arguments passed to it. For example, one would never use a "%s"
substitution based on user data when building an argument set. If for
example I try to deliver to user "foo;/sbin/reboot" and the MTA is dumb
enough to just run the command "mail.local -d %s" substituting the above
string, and mail.local runs as root, you're sunk. This approach means you
don't have to anticipate all the possibilities for all the combinations of
characters you might get from an attacker. The operating system and the
child process (which isn't running as root) validate the data for you.
The child process is free to discover that its parameters are invalid and
report such to the MTA, and no harm befalls the system.

> Also, input and opinions about currently operating MTAs and their
> strengths and weaknesses would be appreciated.

The "SECURITY" file in the current Sendmail open source distribution talks
about some of these issues. Others are just good common programming
practise. I can't speak to the strengths and weaknesses of other MTAs
without spouting what would really be raw opinion rather than fact.

> Let me give you an idea on some of the thoughts that have been going
> through my head regarding MTAs.
>
> 1) I dont want to write a monolithic single binary server that forks off
> parts of itself at different privilege levels to do different tasks. I
> dont know if it is even possible to exploit, but having ALL the
> functions to ALL the different tasks of the MTA in the same address
> space as the instance that accepts user input makes me uneasy.

The design of Sendmail 9 is in progress. It's more in line with this
requirement.

> [...]
> 4) I dont want to modify the directory structure or other misc. bits of
> metadata like directory ownership and permissions of the traditional
> unix mail spools, eg: /var/spool/mqueue, /var/mail (on OpenBSD)

I'm not sure how you can avoid this on UNIX if you're truly security
conscious. Running things as users dedicated to the task (or at least
some non-root unprivileged user like "nobody") is pretty much a necessity,
unless you're willing to certify that your application is bullet-proof and
take the heat when you discover that it isn't.

> Please share your opinions about this idea before I head off on a
> tangent and start a big project that might or might not be fundamentally
> broken due to bad design.

I think anyone who believes writing a secure MTA that handles all of the
specs properly is underestimating what a daunting task that is. It would
be much better to work on improving the security of current
implementations.

-- 
Ralph Logan
CEO/Founder
Camisade
Application Security Innovations
832.496.8448

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]