LPE and RCE in OpenBSD OpenSMTPD

I tested this exploit against an unpatched OpenBSD 6.6 machine and it works with the default mbox delivery, but not with maildir delivery (as hinted by the syspatch message). So if you use maildir delivery like me, you weren&#x27;t exposed to this security hole. This is the sound of the world&#x27;s quietest sigh of relief. I have some questions:<p>Is Qualys getting paid for this excellent work, and if so, by who?<p>Is there a plan to do a serious audit of execle related code in OpenBSD?<p>As a longtime OpenBSD user, I gotta say that OpenSMTPD is the part of the system I&#x27;m least comfortable with from a security standpoint. Too many rewrites, mulligans, CVEs. Very little of the web howtos match the official documentation because there&#x27;s so much churn, which by itself is a red flag. And even without a logic bug, I&#x27;m surprised execle was used at all here. It was unnecessary and naive. I&#x27;ll be honest, I&#x27;m in the middle of transitioning from qmail to OpenSMTPD, and this bug is making me consider notqmail.<p>This RCE is trivial and super bad.

OpenBSD errata and binary syspatches are already available for 6.5&#x2F;6.6.<p><a href="https:&#x2F;&#x2F;man.openbsd.org&#x2F;syspatch" rel="nofollow">https:&#x2F;&#x2F;man.openbsd.org&#x2F;syspatch</a><p><a href="https:&#x2F;&#x2F;www.openbsd.org&#x2F;errata66.html#p018_smtpd_tls" rel="nofollow">https:&#x2F;&#x2F;www.openbsd.org&#x2F;errata66.html#p018_smtpd_tls</a><p><a href="https:&#x2F;&#x2F;www.openbsd.org&#x2F;errata66.html#p019_smtpd_exec" rel="nofollow">https:&#x2F;&#x2F;www.openbsd.org&#x2F;errata66.html#p019_smtpd_exec</a><p>There is also a new portable release of OpenSMTPd - 6.6.2p1: <a href="https:&#x2F;&#x2F;www.mail-archive.com&#x2F;misc@opensmtpd.org&#x2F;msg04850.html" rel="nofollow">https:&#x2F;&#x2F;www.mail-archive.com&#x2F;misc@opensmtpd.org&#x2F;msg04850.htm...</a>

This is such a clean and easy to read write-up on how the control flow led to the bug, and how it’s exploited.<p>Of course, that’s partly because it’s so damn easy to exploit. Here’s what an exploit email actually looks like;<p><pre><code> $ nc 127.0.0.1 25 220 obsd66.example.org ESMTP OpenSMTPD HELO professor.falken 250 obsd66.example.org Hello professor.falken [127.0.0.1], pleased to meet you MAIL FROM:&lt;;sleep 66;&gt; 250 2.0.0 O.k ... </code></pre> That executes “sleep 66” as root.<p>There simply must be a better way to parameterize calls to the MTA that contain <i>remote&#x2F;attacker provided input</i> than exec’ing a shell. It should not all come down to being “absolutely sure” the input is escaped properly.

It seems strange that people are blaming C for this. I see the real problem being that it is a unix pattern to use the shell to pass arguments to programs, even when that input is possibly malicious. Obviously doing this as root takes it from RCE to juggling with plutonium, but a non-confined non-root shell is pretty awful.<p>The code seems to go out of its way to avoid using the system() call to shell out, but then does exactly what system() would do.

It&#x27;s worth noting that this couldn&#x27;t have happened to any mail server running on Plan 9, no matter how buggy it was.<p>Mail servers should run as nobody; mail box files are, in fact, world-writable, and their permissions should reflect that. Go ahead, critique the ergonomics of C&#x27;s conditional expression syntax. But first, consider that this security model for a room full of terminals in the 1970s, where permission to accept connections on port 25 is also permission to format the hard disk, is totally nuts for a network-connected computer in the 2020s.

My main question is why isn&#x27;t &#x2F;bin&#x2F;sh being executed with -r -- restricted mode? It seems weird that a safety-critical piece of code would just call out to &#x2F;bin&#x2F;sh without doing that, especially on openBSD?

Ouch. The root of the issue is that they do a validity check for the local and domain part of the recipient email address. If <i>either</i> one (or both) is invalid, they then check to see if the domain part is empty. If it is, they replace the empty domain with the default domain, and then say it&#x27;s all valid, ignoring the fact that the local part might <i>also</i> be invalid.

I love the copious references to the 80s film WarGames in the examples :)

the PoC can be optimized: after way too much googling, I finally found a way to consume an arbitrary number of non-empty lines without using any special characters. ironically, it uses perl.<p><pre><code> perl -00 -ne exit </code></pre> unfortunately, the first line afterwards is also eaten. this is easily remedied by inserting one junk line though instead of a slide.

Can anyone provide some insight into possible motivations for why the authors may have chosen to use a shell here? I&#x27;m struggling to understand what value it adds over representing mda_command as an array of strings and execving that.<p>I don&#x27;t mean this sarcastically; I&#x27;m genuinely curious about the motivations. The only thing I can come up with is that it&#x27;s slightly more annoying to free an array of strings than it is to free a single string in C. Is that plausibly the only motivation to involve a shell here?

Theo says Web facing things applications is a good place to start using rust, he proved himself right.

Dude this rhymes... Could this be the lyrics for next Openbsd release song?

Wow, Openwall has been really at it when it comes to OpenBSD related vulns.<p>First with the user authentication vulns [0], now this.<p>For those running OpenBSD boxes: the patch is available through syspatch, but you may need to change &#x2F;etc&#x2F;updateurl to an official OpenBSD CDN, since the patch is still fresh and not yet distributed to all mirrors.<p>[0] <a href="https:&#x2F;&#x2F;www.openbsd.org&#x2F;errata65.html" rel="nofollow">https:&#x2F;&#x2F;www.openbsd.org&#x2F;errata65.html</a>

I really wish the OpenBSD team would consider rewriting some of these internet facing services in Go. It would be much safer than C.