
OpenSMTPD advisory dissected - Reventlov
https://poolp.org/posts/2020-01-30/opensmtpd-advisory-dissected/
======
upofadown
This seems pretty classic:

* Five years ago a change causes a logic bug in a not super critical section of code.

* Three and a half years later a change in an entirely different section of code makes the section of code super critical at the same time it makes it exploitable.

Bugs can happen in any of the places you are not looking without actually
changing anything in those places. Your code is full of trip mines and you
don't know where any of the wires are.

------
boring_twenties
The real question is why the fuck does mail delivery need to happen as root in
the first place?

On OpenBSD, mailboxes are mode 600. So, only root can write to them. On Debian
with exim4, they are mode 660 -- writable by group "mail." So the MDA only
needs to run as group mail, not user root.

Is there some reason why OpenBSD is not doing the same thing?

------
protomyth
The "no mail to root" would be a major change. I generally put a .forward to a
common sysadmin account, so I guess I would be curious their solution.

~~~
asveikau
The recommendation I see in a lot of BSD guides and documentation is to use
/etc/mail/aliases to make root's mail go somewhere else. Works slightly
differently from ~/.forward

------
stefan_
It seems very simple for a MTA to be unprivileged: they can join us in the
21st century and drop the whole UNIX maildir, "login into the central terminal
server with your UNIX account to read mail" thing. Write mail into a database
or something, like every other goddamn service out there.

~~~
clarry
Yes, just write it into a database or something, and rewrite the entire
ecosystem to play nice with this new MTA that doesn't compose with existing
tools. Wave hands until the problem solves itself somehow?

~~~
jcranmer
I mean, you'd have to design some sort of Mail Access Protocol to be able to
get to this database, and then get everyone to be able to use that protocol.
Surely that's impossible.

~~~
clarry
So now instead of privileged daemon forking MDAs to deliver everyone their
mail, we have a database holding everyone's mail and everyone's connecting to
that database, presumably through some daemon that can now access everyone's
mail... maybe it doesn't run as root but I'm not convinced this improves the
situation more than it shuffles the point of failure around (and arguably
introduces more of such points).

~~~
jcranmer
I don't know what email service you use, but it's probably storing your email
in a distributed database. An ancillary effect of using an actual database is
that they generally play nicer with backups and actually making sure that you
don't lose any data if the power goes out (doing this yourself is a recipe for
disaster).

Using a database doesn't require a privileged daemon, and the worst-case
scenario (assuming a minimal threshold of competence) is that any attacker can
only screw up the database in some way. With a privileged daemon, screwing up
generally means that the attacker can potentially gain full control of your
hardware, with all the nastiness that entails. Including, at a minimum, read
your email or surreptitiously delete them.

~~~
clarry
I host my own email.

On assuming minimal threshold of competence.. you'd probably want to assume
that nobody today plasters strings (while trying to escape the untrusted bits)
to make SQL queries; many a database have been compromised this way. Here we
are, looking at OpenSMTPD which did essentially the same: pass untrusted
string to shell. Whoops. For anyone whose production email system were subject
to such an issue, it's _bad_ , really bad, whether it's an SQL query going
against unprivileged database with all your data in it, or string going to
root shell.

I'm not terribly concerned about a piece of a daemon running as root. It's not
the entire daemon, just a small privileged helper performing a tiny set of
functions. I'd like to see it go, and I think it could go if we compromise on
some features, change the way MDAs are invoked, or use a different permission
model. The last one would probably be a relatively small change and allow
existing tools to work (perhaps with small changes).

I don't want to introduce a database and a daemon to store messages into it
and another to let me read them. That's just adding more code, I want less
code. I want a better security model, not shuffling responsibility away into a
different daemon that needs to be maintained and audited and protected from a
subtle big whoops.

~~~
juped
It passed a trusted string that it was wrong to trust to the shell. Big
difference, even if some of the ultimate mitigations are the same.

