Re: LPE and RCE in OpenSMTPD's default install (CVE-2020-8794)

                							

                <!--X-Body-Begin-->
<!--X-User-Header-->

oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->

By Date

By Thread

</form>

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
Re: LPE and RCE in OpenSMTPD's default install (CVE-2020-8794)

<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->

From: "Alexander E. Patrakov" &lt;patrakov () gmail com&gt;

Date: Tue, 25 Feb 2020 00:54:50 +0500

<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->

<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
On Mon, Feb 24, 2020 at 10:55 PM Qualys Security Advisory
&lt;qsa () qualys com&gt; wrote:

Qualys Security Advisory

LPE and RCE in OpenSMTPD's default install (CVE-2020-8794)

==============================================================================
Contents
==============================================================================

Summary
Analysis
...
Acknowledgments

==============================================================================
Summary
==============================================================================

We discovered a vulnerability in OpenSMTPD, OpenBSD's mail server. This
vulnerability, an out-of-bounds read introduced in December 2015 (commit
80c6a60c, "when peer outputs a multi-line response ..."), is exploitable
remotely and leads to the execution of arbitrary shell commands: either
as root, after May 2018 (commit a8e22235, "switch smtpd to new
grammar"); or as any non-root user, before May 2018.

Because this vulnerability resides in OpenSMTPD's client-side code
(which delivers mail to remote SMTP servers), we must consider two
different scenarios:

- Client-side exploitation: This vulnerability is remotely exploitable
  in OpenSMTPD's (and hence OpenBSD's) default configuration. Although
  OpenSMTPD listens on localhost only, by default, it does accept mail
  from local users and delivers it to remote servers. If such a remote
  server is controlled by an attacker (either because it is malicious or
  compromised, or because of a man-in-the-middle, DNS, or BGP attack --
  SMTP is not TLS-encrypted by default), then the attacker can execute
  arbitrary shell commands on the vulnerable OpenSMTPD installation.

- Server-side exploitation: First, the attacker must connect to the
  OpenSMTPD server (which accepts external mail) and send a mail that
  creates a bounce. Next, when OpenSMTPD connects back to their mail
  server to deliver this bounce, the attacker can exploit OpenSMTPD's
  client-side vulnerability. Last, for their shell commands to be
  executed, the attacker must (to the best of our knowledge) crash
  OpenSMTPD and wait until it is restarted (either manually by an
  administrator, or automatically by a system update or reboot).

We developed a simple exploit for this vulnerability and successfully
tested it against OpenBSD 6.6 (the current release), OpenBSD 5.9 (the
first vulnerable release), Debian 10 (stable), Debian 11 (testing), and
Fedora 31. At OpenBSD's request, and to give OpenSMTPD's users a chance
to patch their systems, we are withholding the exploitation details and
code until Wednesday, February 26, 2020.

Last-minute note: we tested our exploit against the recent changes in
OpenSMTPD 6.6.3p1, and our results are: if the "mbox" method is used for
local delivery (the default in OpenBSD -current), then arbitrary command
execution as root is still possible; otherwise (if the "maildir" method
is used, for example), arbitrary command execution as any non-root user
is possible.

I would like a bit of clarification. We use OpenSMTPD as a dumb thing
that only relays mail to a central server and never delivers it
locally. The remote server is under our control.

=============
table credentials { smarthost.example.com=myuser:mypassword }

listen on 127.0.0.1

# No local mailboxes
action to_postfix relay host
smtp+tls://smarthost.example.com () smarthost example com auth
&lt;credentials&gt; helo myhostname.example.com
match from local for any action to_postfix
=============

Is the hole exploitable in this configuration?

-- 
Alexander E. Patrakov

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->

<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->

By Date

By Thread

Current thread:

LPE and RCE in OpenSMTPD's default install (CVE-2020-8794) Qualys Security Advisory (Feb 24)

Re: LPE and RCE in OpenSMTPD's default install (CVE-2020-8794) Alexander E. Patrakov (Feb 24)

Re: LPE and RCE in OpenSMTPD's default install (CVE-2020-8794) Qualys Security Advisory (Feb 25)

Re: LPE and RCE in OpenSMTPD's default install (CVE-2020-8794) Qualys Security Advisory (Feb 26)

Re: LPE and RCE in OpenSMTPD's default install (CVE-2020-8794) Alexander E. Patrakov (Feb 29)

Re: LPE and RCE in OpenSMTPD's default install (CVE-2020-8794) Florian Weimer (Mar 01)

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->