Critical opensmtpd vulnerability

[Tobias Geerinckx-Rice]

Fellow Guix running opensmtpd mail servers,

As you probably know by now, a serious remote code execution bug 
was recently found and fixed in OpenSMTPd[0].

TL;DR: You should probably stop your opensmtpd daemon until you've 
checked that our regular opensmtpd package (6.0.3p1) is not 
vulnerable.  If possible, switch to opensmtpd-next and adapt your 
configuration syntax:

   (service opensmtpd-service-type
        (opensmtpd-configuration
         (package opensmtpd-next)
         (config-file (plain-file "smtpd.conf"
                      "include 
                      \"/etc/guix/mail/my-new-smtpd.conf\"\n"))))

Here some stuff I typed before I ran out of time and got on a bus… 
now.

~~~

The issue has been fixed in opensmtpd 6.6.2p1.  I updated our 
‘opensmtpd-next’ package last night (about 18 hours ago, or 1 hour 
after the vulnerability was announced).  If you use opensmtpd-next 
and haven't updated yet, now is the time to do so, as well as the 
time to subscribe to misc at opensmtpd.org.

However!  Guix's opensmtpd-service-type still uses the much older 
‘opensmtpd’ package, which is still at 6.0.x, because 
opensmtpd-next introduced a new and incompatible smtpd.conf 
grammar change.

According to [0], the bug was introduced together with this new 
grammar[1].  It's possible that opensmtpd 6.0.x is not affected.

However, I had a quick look at the 6.0.3p1 sources and 
smtpd/smtp_session.c's

   if (!valid_localpart(maddr->user) ||
       !valid_domainpart(maddr->domain)) {
       /* accept empty return-path in MAIL FROM, required for 
       bounces */
       if (mailfrom && maddr->user[0] == '\0' && maddr->domain[0] 
       == '\0')
           return (1);

       /* no user-part, reject */
       if (maddr->user[0] == '\0')
           return (0);

       /* no domain, local user */
       if (maddr->domain[0] == '\0') {
           (void)strlcpy(maddr->domain, domain,
               sizeof(maddr->domain));
           return (1);
       }
       return (0);
   }

   return (1);

looks pretty damn similar to the logic described here[0].

Kind regards,

T G-R

[0]: https://seclists.org/oss-sec/2020/q1/40
[1]: 
https://www.pf4sh.eu/git/openbsd/src/commit/a8e222352fecfb8aeaf32faf9d0df59b96a447d0

signature.asc
Description: PGP signature