Risks and mitigations
Risks
I’m a C novice.
Most of the code is new, which means it has yet to be reviewed by a wide variety of readers and tested in a wide variety of production environments.
Some of this C novice’s new code runs as root
.
The AUTH code is not new: it’s borrowed from patches that were expecting
to run as qmaild
and I’ve promoted it to run as root
.
There are more moving parts.
Mitigations
They’re small, carefully chosen parts.
authup
is several hundred lines of code that run as root
so that
checkpassword
can drop to the privileges of the authenticated user.
The code is well-worn, derived from qmail-popup
and from SMTP AUTH
patches in common use, and parses input using DJB’s stralloc
library.
If there’s a bug, it’s probably not unique to authup
.
checknotroot
is a couple dozen lines of new code. It calls getuid()
.
If the result is 0, it records the event in ALL CAPS, then exits rather
than run any further programs. The code is so short that there probably
is no security hole.
fixsmtpio
is several hundred lines of new code. It parses input. It
never gets run as root
unless there’s a bug in checknotroot
. The
scope of a security hole is probably constrained to things the user
could do with a full shell: delete, change, or copy off their own data.
(Which is not nothing. If there is such a hole, I’ll want to fix it
ASAP.) fixsmtpio
is covered fairly well by automated tests.
qmail-qfilter-addtlsheader
is a few dozen lines of new code. It writes
its stdin to stdout, prepending a Received:
header if certain TLS
environment variables are present. The code is so short that there
probably is no security hole.