Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Oct 2015 07:49:33 -0700
From: Qualys Security Advisory <qsa@...lys.com>
To: oss-security@...ts.openwall.com
Subject: Qualys Security Advisory - OpenSMTPD Audit Report

(Sorry for the "CVE-2015-ABCD" place-holders in the report, but
OpenSMTPD's developers were ready with the patches before MITRE was
ready with the CVE-IDs.)


Qualys Security Advisory

OpenSMTPD Audit Report


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

Summary
Approach
Local Vulnerabilities
Remote Vulnerabilities
Inter-Process Vulnerabilities
Miscellaneous Bugs
Acknowledgments


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

For the past few months, one of our background projects has been to
audit OpenSMTPD, a free implementation of the server-side Simple Mail
Transfer Protocol (SMTP). OpenSMTPD replaces Sendmail as OpenBSD's
default Mail Transfer Agent (MTA) since OpenBSD 5.6, released on
November 1, 2014.

OpenSMTPD was designed to be secure, reliable, performant, and easy to
configure. Indeed, its codebase lives up to OpenBSD's reputation: it is
clean, modular, privilege-separated, and made our audit easy and really
enjoyable. However, the project is pretty much in its infancy (the first
stable version, 5.3, was released on March 17, 2013), which explains why
we discovered various vulnerabilities during our security assessment:

- an oversight in the portable version of fgetln() that allows attackers
  to read and write out-of-bounds memory;

- multiple denial-of-service vulnerabilities that allow local users to
  kill or hang OpenSMTPD;

- a stack-based buffer overflow that allows local users to crash
  OpenSMTPD, or execute arbitrary code as the non-chrooted _smtpd user;

- a hardlink attack (or race-conditioned symlink attack) that allows
  local users to unset the chflags() of arbitrary files;

- a hardlink attack that allows local users to read the first line of
  arbitrary files (for example, root's hash from /etc/master.passwd);

- a denial-of-service vulnerability that allows remote attackers to fill
  OpenSMTPD's queue or mailbox hard-disk partition;

- an out-of-bounds memory read that allows remote attackers to crash
  OpenSMTPD, or leak information and defeat the ASLR protection;

- a use-after-free vulnerability that allows remote attackers to crash
  OpenSMTPD, or execute arbitrary code as the non-chrooted _smtpd user;

- multiple inter-process vulnerabilities that allow attackers to
  escalate from one (already-compromised) OpenSMTPD process to another.


========================================================================
Approach
========================================================================

The OpenSMTPD version that we audited is available at:

https://www.opensmtpd.org/archives/opensmtpd-5.4.4p1.tar.gz

and is installed by default on OpenBSD's latest release (OpenBSD 5.7,
released on May 1, 2015). Unless otherwise noted, the vulnerabilities
that we discovered in OpenSMTPD 5.4.4p1 affect OpenSMTPD's latest
release as well (OpenSMTPD 5.7.1p1, released on June 30, 2015).

The "hybrid approach" that we adopted to review OpenSMTPD is described
in the bible of code auditing, "The Art of Software Security Assessment"
(by Mark Dowd, John McDonald, and Justin Schuh):

- We started with a "top-down approach" and reviewed the high-level
  information that we gathered on OpenSMTPD: READMEs, manual pages, web
  pages (https://www.opensmtpd.org/presentations/asiabsdcon2013-smtpd/
  and https://www.poolp.org/).

  This approach allowed us to quickly understand OpenSMTPD's design
  (seven privilege-separated, long-running, and event-driven processes
  that communicate through UNIX sockets and the imsg API) and identify
  its attack surface (local, remote, and inter-process entry points).

- We continued with a "bottom-up approach" and reviewed OpenSMTPD's
  implementation: the lowest-level code first (openbsd-compat/ and
  smtpd/mproc.c), followed by the higher-level code.

  This approach allowed us to quickly identify complex vulnerabilities:
  the remote out-of-bounds memory read and use-after-free are actually a
  combination of several low-level and high-level bugs.

------------------------------------------------------------------------
Privilege Separation
------------------------------------------------------------------------

--[ PROC_PARENT ]-------------------------------------------------------

User: root

Chroot: no

Peers: PROC_CONTROL, PROC_LKA, PROC_QUEUE, PROC_CA, PROC_PONY

PROC_PARENT, the "[priv]" process, spawns the six other long-running
processes at startup (by calling fork_peers() from main()), and the
transient Mail Delivery Agent (MDA) processes on demand (by calling
forkmda() from parent_imsg()).

If any of its long-running children dies, PROC_PARENT calls
parent_shutdown(), kill()s its remaining children, and exit()s, but does
not restart automatically: if we try to exploit a memory corruption, we
have to come up with a one-shot, not a brute-force.

--[ PROC_CONTROL ]------------------------------------------------------

User: _smtpd

Chroot: /var/empty

Peers: PROC_SCHEDULER, PROC_QUEUE, PROC_PARENT, PROC_LKA, PROC_PONY,
PROC_CA

PROC_CONTROL, the "control" process, handles messages from the control
socket "/var/run/smtpd.sock" (by calling control_dispatch_ext()), and
gathers statistics from its peers (by calling control_imsg()).

--[ PROC_PONY ]---------------------------------------------------------

User: _smtpd

Chroot: /var/empty

Peers: PROC_PARENT, PROC_QUEUE, PROC_LKA, PROC_CONTROL, PROC_CA

PROC_PONY, the "pony express" process
(https://en.wikipedia.org/wiki/Pony_Express), handles the server-side
SMTP sessions (by calling smtp_imsg()), the client-side MTA sessions (by
calling mta_imsg()), and the local MDA deliveries (by calling
mda_imsg()).

--[ PROC_LKA ]----------------------------------------------------------

User: _smtpd

Chroot: no (needs access to /etc/resolv.conf and /etc/ssl/cert.pem)

Peers: PROC_PARENT, PROC_QUEUE, PROC_CONTROL, PROC_PONY

PROC_LKA, the "lookup" process, performs all lookups on behalf of the
other processes: asynchronous DNS resolution (by calling dns_imsg() and
libasr), user information and credentials lookup, SSL certificate
verification, alias expansion (by calling lka_imsg()).

--[ PROC_QUEUE ]--------------------------------------------------------

User: _smtpq (or _smtpd if _smtpq does not exist)

Chroot: /var/spool/smtpd

Peers: PROC_PARENT, PROC_CONTROL, PROC_LKA, PROC_SCHEDULER, PROC_PONY

PROC_QUEUE, the "queue" process, manages the persistent storage of
messages and envelopes (by calling queue_imsg()). By default, the
smtpd/queue_fs.c backend is used.

--[ PROC_SCHEDULER ]----------------------------------------------------

User: _smtpd

Chroot: /var/empty

Peers: PROC_CONTROL, PROC_QUEUE

PROC_SCHEDULER, the "scheduler" process, knows about all existing
messages and envelopes (by calling scheduler_imsg()), and decides when
to relay or deliver them. By default, the smtpd/scheduler_ramqueue.c
backend is used.

--[ PROC_CA ]-----------------------------------------------------------

User: _smtpd

Chroot: /var/empty

Peers: PROC_CONTROL, PROC_PARENT, PROC_PONY

PROC_CA, the "klondike" process
(https://en.wikipedia.org/wiki/Klondike_Gold_Rush), performs
privilege-separated RSA encryption and decryption on behalf of PROC_PONY
(by calling ca_imsg()).

------------------------------------------------------------------------
Attack Surface
------------------------------------------------------------------------

--[ Local Vectors ]-----------------------------------------------------

----[ .forward

Local users may put a .forward file in their home directory in order to
control how their incoming email is processed and delivered.

When PROC_PONY receives a CMD_RCPT_TO from one of its SMTP clients, it
sends an IMSG_SMTP_EXPAND_RCPT to PROC_LKA. If the recipient is a local
user, the (unprivileged) PROC_LKA sends an IMSG_LKA_OPEN_FORWARD to the
(privileged) PROC_PARENT. If PROC_PARENT manages to open() the user's
.forward file, it sends its file descriptor back to PROC_LKA, which
parses and expands its contents.

----[ Control Socket

PROC_CONTROL calls getpeereid(), or getsockopt(SO_PEERCRED), in order to
determine the credentials of the clients that connect to its UNIX socket
"/var/run/smtpd.sock". It processes all the messages received from
connections initiated by root, but otherwise processes only the
IMSG_CTL_SMTP_SESSION and forwards it to PROC_PONY.

Clients normally connect to the control socket with the command-line
program "smtpctl", but we may also connect() to it directly, should we
ever want to exploit a vulnerability in the imsg API, for example.

----[ Offline Directory

The command-line program "smtpctl" can be used to send email (when
invoked as "sendmail"): it connects to the control socket, sends an
IMSG_CTL_SMTP_SESSION to PROC_CONTROL (which forwards it to PROC_PONY),
and enqueues the email through this local SMTP session (enqueue() in
smtpd/enqueue.c).

However, if OpenSMTPD is not running, the connection to the control
socket will fail, and "smtpctl" will simply store the email into the
"/var/spool/smtpd/offline" directory, which is mode 01777
(enqueue_offline() in smtpd/enqueue.c).

Later, when OpenSMTPD restarts, it will execvp() "smtpctl" for each
email stored in the offline directory, exactly as if its owner had just
submitted it for the first time (offline_enqueue() in smtpd/smtpd.c).

--[ Remote Vectors ]----------------------------------------------------

----[ SMTP Client

By default, OpenSMTPD is configured to accept email from local users,
and connects to remote SMTP servers in order to relay and deliver it.
The code for these client-side MTA sessions (smtpd/mta_session.c) is
reachable remotely (and is also used for bounces) and represents an
important attack vector.

----[ SMTP Server

OpenSMTPD can be configured to accept email from remote SMTP clients,
and relay or deliver it to local users. The code for these server-side
SMTP sessions (smtpd/smtp_session.c) is reachable remotely and
represents another important attack vector.

----[ DNS Resolver

The libasr, an asynchronous DNS resolver, is used by OpenSMTPD and
represents yet another remote vector. However, its codebase is pretty
much independent and therefore beyond the scope of our OpenSMTPD audit.
The same can be said of OpenSSL and LibreSSL.

--[ Inter-Process Vectors ]---------------------------------------------

If we ever manage to compromise one of OpenSMTPD's processes, a
vulnerability in the inter-process communication code may allow us to
escalate from an unprivileged, chrooted process to a privileged,
non-chrooted process. For example, pivoting from PROC_PONY to
PROC_PARENT, or even PROC_LKA, would be a good move.


========================================================================
Local Vulnerabilities
========================================================================

------------------------------------------------------------------------
CVE-2015-ABCD - Portable fgetln() can return a zero length
------------------------------------------------------------------------

Constructs similar to the following appear several times throughout
OpenSMTPD's codebase:

        while ((buf = fgetln(fp, &len))) {
                if (buf[len - 1] == '\n')
                        buf[len - 1] = '\0';

and:

                        line = fgetln(s->msgfp, &len);
                        if (line == NULL) break;
                        line[len - 1] = '\0';

In theory, if fgetln() succeeds (i.e., does not return NULL) but stores
a 0 length in len, an out-of-bounds memory read and (possibly) write is
triggered. In practice, this is impossible because OpenBSD's libc
implementation of fgetln() guarantees what the manpage says:

        The length of the line, including the final newline, is stored
        in the memory location to which len points and is guaranteed to
        be greater than 0 upon successful completion.

Unfortunately, the portable implementation of fgetln() in
openbsd-compat/fgetln.c (which is used on Linux, at least) offers no
such guarantee:

 38 char *
 39 fgetln(stream, len)
 40     FILE *stream;
 41     size_t *len;
 42 {
 ..
 50     if (fgets(buffer, buflen+1, stream) == NULL)
 51         return NULL;
 52     *len = strlen(buffer);
 ..
 60     return buffer;
 61 }

For example, if fgets() reads the line "\0\n", fgetln() succeeds and
stores a 0 string-length in len (which should be impossible), and the
out-of-bounds memory is accessed upon return.

------------------------------------------------------------------------
CVE-2015-ABCD - Local denial-of-service (invalid imsg)
------------------------------------------------------------------------

The fatalx(NULL) in mproc_dispatch() can be triggered locally by
connecting directly to the control socket and sending an invalid imsg
(one that is smaller than IMSG_HEADER_SIZE or larger than MAX_IMSGSIZE).
imsg_get() will fail, fatalx() will be called, and PROC_CONTROL will
exit() (and, as mentioned earlier, if one OpenSMTPD process dies, all
OpenSMTPD processes die):

187                 if ((n = imsg_get(&p->imsgbuf, &imsg)) == -1) {
188                         log_warn("fatal: %s: error in imsg_get for %s",
189                             proc_name(smtpd_process),  p->name);
190                         fatalx(NULL);
191                 }

This local denial-of-service has been discovered independently by
OpenSMTPD's developers and fixed in version 5.4.6p1 (released on June
11, 2015):

188                 if ((n = imsg_get(&p->imsgbuf, &imsg)) == -1) {
189
190                         if (smtpd_process == PROC_CONTROL &&
191                             p->proc == PROC_CLIENT) {
192                                 log_warnx("warn: client sent invalid imsg "
193                                     "over control socket");
194                                 p->handler(p, NULL);
195                                 return;
196                         }
197                         log_warn("fatal: %s: error in imsg_get for %s",
198                             proc_name(smtpd_process),  p->name);
199                         fatalx(NULL);
200                 }

------------------------------------------------------------------------
CVE-2015-ABCD - Local denial-of-service (file-descriptor exhaustion)
------------------------------------------------------------------------

By connecting locally to the control socket and passing many file
descriptors (~1024) to PROC_CONTROL (which does not really expect this),
it is possible to exhaust almost all of its available fds.

- In OpenSMTPD 5.4.4p1, PROC_CONTROL ends up calling fatal("exiting") in
  mproc_dispatch():

153                 if ((n = imsg_read(&p->imsgbuf)) == -1) {
154                         log_warn("warn: %s -> %s: imsg_read",
155                             proc_name(smtpd_process),  p->name);
156                         fatal("exiting");
157                 }

- In OpenSMTPD 5.7.1p1, PROC_CONTROL does not call fatal("exiting")
  (thanks to the EAGAIN check at the beginning of mproc_dispatch()), but
  it will never again accept new client connections (because of how
  control_accept() handles file-descriptor exhaustion):

155                 if ((n = imsg_read(&p->imsgbuf)) == -1) {
156                         log_warn("warn: %s -> %s: imsg_read",
157                             proc_name(smtpd_process),  p->name);
158                         if (errno == EAGAIN)
159                                 return;
160                         fatal("exiting");
161                 }

There are actually three different ways to trigger this local
denial-of-service:

1/ Send one fd per imsg, with the IMSGF_HASFD flag turned on: imsg_get()
will move the fd from ibuf->fds to imsg->fd, but because PROC_CONTROL
does not expect a fd to be passed, this fd is leaked forever when
imsg_free() is called by mproc_dispatch().

2/ Send one fd per imsg, but with the IMSGF_HASFD flag turned off:
imsg_get() will leave the fd in ibuf->fds, which are supposed to be
closed when control_close() is called, but this never happens if all fds
are exhausted first.

3/ Send only one large (>1024) imsg, one byte at a time, with one fd
attached to every single byte sent: this will accumulate all passed fds
into ibuf->fds.

------------------------------------------------------------------------
CVE-2015-ABCD - Local denial-of-service (connection-id wrap)
------------------------------------------------------------------------

In control_accept(), it is possible to trigger the errx() of the
following tree_xset() call:

348         c = xcalloc(1, sizeof(*c), "control_accept");
349         if (getpeereid(connfd, &c->euid, &c->egid) == -1)
350                 fatal("getpeereid");
351         c->id = ++connid;
352         c->mproc.proc = PROC_CLIENT;
353         c->mproc.handler = control_dispatch_ext;
354         c->mproc.data = c;
355         mproc_init(&c->mproc, connfd);
356         mproc_enable(&c->mproc);
357         tree_xset(&ctl_conns, c->id, c);

If we establish a first connection to the control socket (and keep it
alive), and then establish (and immediately close) new connections in a
loop, the "static uint32_t connid" will eventually wrap and collide with
our (kept-alive) first connection id, and the exclusive tree_xset() will
fail and terminate PROC_CONTROL with errx().

------------------------------------------------------------------------
CVE-2015-ABCD - Local denial-of-service (WIFSTOPPED() child)
------------------------------------------------------------------------

In parent_sig_handler(), it is possible to trigger the following
fatalx() call:

 366                         pid = waitpid(-1, &status, WNOHANG);
 367                         if (pid <= 0)
 368                                 continue;
 ...
 371                         if (WIFSIGNALED(status)) {
 ...
 375                         } else if (WIFEXITED(status)) {
 ...
 381                         } else
 382                                 fatalx("smtpd: unexpected cause of SIGCHLD");

If the child is ptraced, WIFSIGNALED() and WIFEXITED() can return false,
but WIFSTOPPED() can return true, even if WUNTRACED was not specified in
waitpid(). In order to trigger this in the context of OpenSMTPD, a local
user can add a "|exec /tmp/ptraceme" line to his ~/.forward file, where
ptraceme is a small program that simply calls ptrace(PT_TRACE_ME) and
execve() (it does not matter which binary is executed).

------------------------------------------------------------------------
CVE-2015-ABCD - Local denial-of-service (blocking open() call)
------------------------------------------------------------------------

The open() call in parent_forward_open() can block forever (if the
~/.forward was created by mkfifo, for example) and this will effectively
block OpenSMTPD as a whole (PROC_PARENT will not respond to
IMSG_LKA_OPEN_FORWARD and IMSG_MDA_FORK requests anymore):

1232         if (! bsnprintf(pathname, sizeof (pathname), "%s/.forward",
1233                 directory))
1234                 fatal("smtpd: parent_forward_open: snprintf");
....
1247         do {
1248                 fd = open(pathname, O_RDONLY);
1249         } while (fd == -1 && errno == EINTR);

------------------------------------------------------------------------
Multiple hardlink attacks in the offline directory
------------------------------------------------------------------------

In the world-writable "/var/spool/smtpd/offline" directory, local users
can create hardlinks to files they do not own, and wait until the server
reboots (or, crash OpenSMTPD with a denial-of-service and wait until the
administrator restarts it) to carry out assorted attacks.

1/ The following code in offline_enqueue() allows an attacker to
chflags(0) arbitrary files, by hardlinking them to the offline directory
(CVE-2015-ABCD):

1117                 if (lstat(path, &sb) == -1) {
1118                         log_warn("warn: smtpd: lstat: %s", path);
1119                         _exit(1);
1120                 }
1121
1122 #ifdef HAVE_CHFLAGS
1123                 if (chflags(path, 0) == -1) {
1124                         log_warn("warn: smtpd: chflags: %s", path);
1125                         _exit(1);
1126                 }
1127 #endif

2/ The following code in offline_enqueue() allows an attacker to
execvp() "/usr/sbin/smtpctl" as "sendmail", with a command-line argument
that is the hardlinked file's first line (CVE-2015-ABCD):

1149                 if ((fp = fopen(path, "r")) == NULL)
1150                         _exit(1);
....
1160                 if ((p = fgetln(fp, &len)) == NULL)
1161                         _exit(1);
....
1167                 addargs(&args, "%s", "sendmail");
1168
1169                 while ((tmp = strsep(&p, "|")) != NULL)
1170                         addargs(&args, "%s", tmp);
....
1179                 execvp(PATH_SMTPCTL, args.list);
1180                 _exit(1);

For example, an attacker can hardlink /etc/master.passwd to the offline
directory, and retrieve its first line (root's encrypted password) by
running ps (or a small program that simply calls sysctl() with
KERN_FILE_BYUID and KERN_PROC_ARGV) in a loop:

In the attacker's terminal:

$ ln /etc/master.passwd /var/spool/smtpd/offline
$ ./getargs &
[1] 23460

In the administrator's terminal:

# /etc/rc.d/smtpd restart
smtpd(ok)
smtpd(ok)

On the attacker's terminal:

root:$2b$09$pN5WRvGaiPHEXPsrIwSNWe1S0U5iTIvtWqPQgHmd0BAJK02GOYG.W:0:0:daemon:0:0:Charlie &:/root:/bin/ksh

3/ If an attacker controls at least part of another user's file, he can
hardlink this file to the offline directory, and try to exploit one of
the vulnerable fgetln() calls in the enqueue code, which runs with the
privileges of this other user. For example, in offline_enqueue():

1160                 if ((p = fgetln(fp, &len)) == NULL)
1161                         _exit(1);
1162
1163                 if (p[len - 1] != '\n')
1164                         _exit(1);
1165                 p[len - 1] = '\0';

And in savedeadletter():

898         while ((buf = fgetln(in, &len))) {
899                 if (buf[len - 1] == '\n')
900                         buf[len - 1] = '\0';

However, we did not investigate this vector any further, because on
OpenBSD (where an attacker is allowed to hardlink another user's file)
fgetln() is not vulnerable, and on Linux (where fgetln() is vulnerable)
an attacker is usually not allowed to hardlink another user's file.

4/ If an attacker is able to reach another user's file (i.e., +x on all
directories that lead to the file) but not read it, he can hardlink the
file to the offline directory, and wait for savedeadletter() to create a
world-readable copy of the file in this other user's home directory:

854         (void)snprintf(buffer, sizeof buffer, "%s/dead.letter", pw->pw_dir);
...
859         if ((fp = fopen(buffer, "w")) == NULL)
860                 return 0;
...
898         while ((buf = fgetln(in, &len))) {
...
909                 fprintf(fp, "%s\n", buf);
910         }

However, there are three reasons why this particular vector is useless
in practice:

a) In OpenSMTPD 5.4.4p1, the getlogin() call in enqueue() will always
return "root", which means that the world-readable "dead.letter" will
always be created in /root, unreachable by the attacker (drwx------).

b) In OpenSMTPD 5.4.5p2, smtpctl's -S command-line option was added to
work around the getlogin() problem, but the getopt() string was
incorrectly modified to "RS:" instead of "R:S".

c) In OpenSMTPD 5.7.1p1, the getopt() string was fixed to "R:S", but the
savedeadletter() code was removed altogether.

------------------------------------------------------------------------
CVE-2015-ABCD - .forward stack-based buffer overflow
------------------------------------------------------------------------

In lka_expand_format(), the exptoklen bytes returned by
lka_expand_token() are memcpy()ed to ptmp (a pointer into the
stack-based tmpbuf) without first checking that there is enough space
left in tmpbuf:

799                 exptoklen = lka_expand_token(exptok, sizeof exptok, token, ep,
800                     ui);
801                 if (exptoklen == 0)
802                         return 0;
803
804                 memcpy(ptmp, exptok, exptoklen);

This stack-based buffer overflow can be triggered locally through
OpenSMTPD's .forward mechanism:

$ whoami
john

$ python -c 'print "/" * 1014 + "%{sender}"' > ~/.forward

$ python -c 'print "A" * 255 + "@" + "A" * 255'
AAA...AAA@......AAA

$ telnet 127.0.0.1 25
EHLO 127.0.0.1
MAIL FROM:<AAA...AAA@......AAA>
RCPT TO:<john@...alhost>
Connection closed by foreign host.

As a result, in the logs:

smtpd[9305]: warn: format string error while expanding for user john
smtpd: stack overflow in function lka_submit

It does not appear to be exploitable on OpenBSD x86 (beyond a local
denial-of-service), where even a one-byte overflow ended up smashing the
stack canary of every smtpd binary we tried. However, it may lead to
arbitrary code execution on other operating systems or platforms.


========================================================================
Remote Vulnerabilities
========================================================================

------------------------------------------------------------------------
CVE-2015-ABCD - Remote denial-of-service (disk-space exhaustion)
------------------------------------------------------------------------

The maximum size of an email, env->sc_maxsize (by default 35 megabytes),
is enforced in dataline_callback() for the email's body:

 266         len = strlen(line) + 1;
 267
 268         if (s->datalen + len > env->sc_maxsize) {
 269                 s->msgflags |= MF_ERROR_SIZE;
 270                 return;
 271         }
 ...
 278         s->datalen += len;

but not in header_default_callback() for the email's headers:

 243         len = strlen(hdr->name) + 1;
 ...
 248         s->datalen += len;
 249
 250         TAILQ_FOREACH(l, &hdr->lines, next) {
 251                 len = strlen(l->buffer) + 1;
 ...
 256                 s->datalen += len;
 257         }

It is therefore possible to send a headers-only email (i.e., no empty
line between the last header and the DATA-ending ".") that is much
larger than 35 megabytes, and fill OpenSMTPD's queue or mailbox
hard-disk partition.

------------------------------------------------------------------------
Multiple vulnerabilities in IMSG_{SMTP,MTA}_SSL_VERIFY*
------------------------------------------------------------------------

These IMSG_{SMTP,MTA}_SSL_VERIFY* messages are exchanged between
PROC_PONY and PROC_LKA:

- after PROC_PONY successfully established an SSL connection with an
  SMTP client (a client-certificate request is always made, but not
  necessarily responded to), it calls smtp_verify_certificate() and
  sends a few IMSG_SMTP_SSL_VERIFY* messages to PROC_LKA, which verifies
  the client's SSL certificate (if any) on behalf of PROC_PONY.

- after PROC_PONY successfully established an SSL connection with an
  SMTP server (opportunistic STARTTLS encryption is always attempted,
  but not necessarily successful), it calls mta_verify_certificate() and
  sends a few IMSG_MTA_SSL_VERIFY* messages to PROC_LKA, which verifies
  the server's SSL certificate on behalf of PROC_PONY.

In lka_imsg(), PROC_LKA blindly trusts the contents of the
req_ca_vrfy_smtp, req_ca_vrfy_mta, and req_ca_vrfy_chain structures that
it receives from PROC_PONY (although this suggests vulnerabilities that
are inter-process only, they are also triggerable remotely through two
other low-level bugs in imsg and mproc, to be described shortly):

struct ca_vrfy_req_msg {
        uint64_t                reqid;
        char                    pkiname[SMTPD_MAXHOSTNAMELEN];
        unsigned char          *cert;
        off_t                   cert_len;
        size_t                  n_chain;
        size_t                  chain_offset;
        unsigned char         **chain_cert;
        off_t                  *chain_cert_len;
};

 63 static void
 64 lka_imsg(struct mproc *p, struct imsg *imsg)
 65 {
 ..
 70         static struct ca_vrfy_req_msg   *req_ca_vrfy_smtp = NULL;
 71         static struct ca_vrfy_req_msg   *req_ca_vrfy_mta = NULL;
 72         struct ca_vrfy_req_msg          *req_ca_vrfy_chain;

- In the IMSG_{SMTP,MTA}_SSL_VERIFY_{CERT,CHAIN} cases, PROC_LKA
  attempts to read cert_len bytes from imsg->data, but does not check
  first that PROC_PONY actually sent this amount of data (out-of-bounds
  memory read, CVE-2015-ABCD):

148                 case IMSG_SMTP_SSL_VERIFY_CERT:
149                         req_ca_vrfy_smtp = xmemdup(imsg->data, sizeof *req_ca_vrfy_smtp, "lka:ca_vrfy");
150                         req_ca_vrfy_smtp->cert = xmemdup((char *)imsg->data +
151                             sizeof *req_ca_vrfy_smtp, req_ca_vrfy_smtp->cert_len, "lka:ca_vrfy");

158                 case IMSG_SMTP_SSL_VERIFY_CHAIN:
159                         if (req_ca_vrfy_smtp == NULL)
160                                 fatalx("lka:ca_vrfy: chain without a certificate");
161                         req_ca_vrfy_chain = imsg->data;
162                         req_ca_vrfy_smtp->chain_cert[req_ca_vrfy_smtp->chain_offset] = xmemdup((char *)imsg->data +
163                             sizeof *req_ca_vrfy_chain, req_ca_vrfy_chain->cert_len, "lka:ca_vrfy");

- In the IMSG_{SMTP,MTA}_SSL_VERIFY_CERT case, PROC_LKA does not
  sanity-check n_chain, the number of certificates in the chain that
  will be sent by PROC_PONY:

148                 case IMSG_SMTP_SSL_VERIFY_CERT:
149                         req_ca_vrfy_smtp = xmemdup(imsg->data, sizeof *req_ca_vrfy_smtp, "lka:ca_vrfy");
150                         req_ca_vrfy_smtp->cert = xmemdup((char *)imsg->data +
151                             sizeof *req_ca_vrfy_smtp, req_ca_vrfy_smtp->cert_len, "lka:ca_vrfy");
152                         req_ca_vrfy_smtp->chain_cert = xcalloc(req_ca_vrfy_smtp->n_chain,
153                             sizeof (unsigned char *), "lka:ca_vrfy");
154                         req_ca_vrfy_smtp->chain_cert_len = xcalloc(req_ca_vrfy_smtp->n_chain,
155                             sizeof (off_t), "lka:ca_vrfy");
156                         return;

- In the IMSG_{SMTP,MTA}_SSL_VERIFY_{CERT,CHAIN} cases, PROC_LKA does
  not sanity-check chain_offset (out-of-bounds memory write,
  CVE-2015-ABCD):

  . in the IMSG_{SMTP,MTA}_SSL_VERIFY_CERT case, chain_offset should be
    initialized to 0, but PROC_LKA trusts PROC_PONY to do so (arbitrary
    memory write);

  . in the IMSG_{SMTP,MTA}_SSL_VERIFY_CHAIN case, chain_offset should be
    checked against n_chain, but PROC_LKA trusts PROC_PONY to send no
    more than n_chain certificates (heap-based buffer overflow):

158                 case IMSG_SMTP_SSL_VERIFY_CHAIN:
159                         if (req_ca_vrfy_smtp == NULL)
160                                 fatalx("lka:ca_vrfy: chain without a certificate");
161                         req_ca_vrfy_chain = imsg->data;
162                         req_ca_vrfy_smtp->chain_cert[req_ca_vrfy_smtp->chain_offset] = xmemdup((char *)imsg->data +
163                             sizeof *req_ca_vrfy_chain, req_ca_vrfy_chain->cert_len, "lka:ca_vrfy");
164                         req_ca_vrfy_smtp->chain_cert_len[req_ca_vrfy_smtp->chain_offset] = req_ca_vrfy_chain->cert_len;
165                         req_ca_vrfy_smtp->chain_offset++;
166                         return;

- In the IMSG_{SMTP,MTA}_SSL_VERIFY case, PROC_LKA does not reset the
  static pointer req_ca_vrfy_{smtp,mta} to NULL after free(), but trusts
  PROC_PONY to always send an IMSG_{SMTP,MTA}_SSL_VERIFY_CERT (which
  re-initializes this static pointer) before sending an
  IMSG_{SMTP,MTA}_SSL_VERIFY{_CHAIN,} (use-after-free, CVE-2015-ABCD):

168                 case IMSG_SMTP_SSL_VERIFY:
169                         if (req_ca_vrfy_smtp == NULL)
170                                 fatalx("lka:ca_vrfy: verify without a certificate");
...
185                         for (i = 0; i < req_ca_vrfy_smtp->n_chain; ++i)
186                                 free(req_ca_vrfy_smtp->chain_cert[i]);
187                         free(req_ca_vrfy_smtp->chain_cert);
188                         free(req_ca_vrfy_smtp->chain_cert_len);
189                         free(req_ca_vrfy_smtp->cert);
190                         free(req_ca_vrfy_smtp);
191                         return;

------------------------------------------------------------------------
CVE-2015-ABCD - Integer truncation in the imsg API
------------------------------------------------------------------------

There is a fundamental design flaw in the imsg_create(), imsg_add(), and
imsg_compose() functions (and imsg_composev(), which calls imsg_create()
and imsg_add()): their datalen argument is directly an u_int16_t, a fact
that is easily overlooked by their callers and makes them vulnerable to
integer truncation.

In OpenSMTPD, the nearly-identical functions smtp_verify_certificate()
and mta_verify_certificate() are vulnerable to this integer truncation,
and both are reachable remotely through SSL certificate verification:

2046 static int
2047 smtp_verify_certificate(struct smtp_session *s)
2048 {
....
2056         x = SSL_get_peer_certificate(s->io.ssl);
....
2059         xchain = SSL_get_peer_cert_chain(s->io.ssl);
....
2071         /* Send the client certificate */
2072         memset(&req_ca_vrfy, 0, sizeof req_ca_vrfy);
....
2083         req_ca_vrfy.cert_len = i2d_X509(x, &req_ca_vrfy.cert);
2084         if (xchain)
2085                 req_ca_vrfy.n_chain = sk_X509_num(xchain);
2086         iov[0].iov_base = &req_ca_vrfy;
2087         iov[0].iov_len = sizeof(req_ca_vrfy);
2088         iov[1].iov_base = req_ca_vrfy.cert;
2089         iov[1].iov_len = req_ca_vrfy.cert_len;
2090         m_composev(p_lka, IMSG_SMTP_SSL_VERIFY_CERT, 0, 0, -1,
2091             iov, nitems(iov));
....
2095         if (xchain) {
2096                 /* Send the chain, one cert at a time */
2097                 for (i = 0; i < sk_X509_num(xchain); ++i) {
2098                         memset(&req_ca_vrfy, 0, sizeof req_ca_vrfy);
....
2100                         x = sk_X509_value(xchain, i);
2101                         req_ca_vrfy.cert_len = i2d_X509(x, &req_ca_vrfy.cert);
2102                         iov[0].iov_base = &req_ca_vrfy;
2103                         iov[0].iov_len  = sizeof(req_ca_vrfy);
2104                         iov[1].iov_base = req_ca_vrfy.cert;
2105                         iov[1].iov_len  = req_ca_vrfy.cert_len;
2106                         m_composev(p_lka, IMSG_SMTP_SSL_VERIFY_CHAIN, 0, 0, -1,
2107                             iov, nitems(iov));
....
2109                 }
2110         }
2111
2112         /* Tell lookup process that it can start verifying, we're done */
2113         memset(&req_ca_vrfy, 0, sizeof req_ca_vrfy);
....
2115         m_compose(p_lka, IMSG_SMTP_SSL_VERIFY, 0, 0, -1,
2116             &req_ca_vrfy, sizeof req_ca_vrfy);
....
2119 }

If the cert_len returned by i2d_X509() exceeds 64k, integer truncation
occurs when m_composev() calls imsg_composev(). The following #define
from OpenSSL and LibreSSL confirms that this is indeed possible:

#define SSL_MAX_CERT_LIST_DEFAULT 1024*100 /* 100k max cert list :-) */

Surprisingly, this integer truncation in PROC_PONY triggers the
out-of-bounds memory read in PROC_LKA: xmemdup() tries to read cert_len
bytes (the non-truncated cert_len) from imsg->data, which contains only
the truncated number of cert_len bytes (i.e., xmemdup() tries to read an
extra 64k from imsg->data).

Our initial research suggests that this out-of-bounds memory read can be
transformed into a remote information leak that reveals heap addresses
and defeats the ASLR protection. Linux is almost certainly exploitable,
but OpenBSD's heavily randomized and hardened malloc significantly
raises the bar for successful exploitation.

------------------------------------------------------------------------
CVE-2015-ABCD - Missing return-value checks in the mproc API
------------------------------------------------------------------------

The m_forward(), m_compose(), and m_composev() functions do not check
the return value of imsg_compose() and imsg_composev(): if the message
to be sent is larger than MAX_IMSGSIZE (16k), these three functions will
fail to send the message, but they will not report this failure to their
callers, which have therefore no way of knowing whether the message was
actually sent or not.

Again, smtp_verify_certificate() and mta_verify_certificate() are
vulnerable: if the peer's certificate is larger than 16k (but smaller
than 64k, in order to avoid the integer truncation), PROC_PONY will fail
to send the IMSG_{SMTP,MTA}_SSL_VERIFY_CERT to PROC_LKA, and the
subsequent IMSG_{SMTP,MTA}_SSL_VERIFY_CHAIN will trigger the
use-after-free in PROC_LKA, which in turn will trigger the out-of-bounds
memory write in PROC_LKA.

Our initial research suggests that this use-after-free (and
out-of-bounds memory write) can be transformed into remote code
execution, when combined with the information leak described above.
Linux is almost certainly exploitable, but again, OpenBSD's heavily
randomized and hardened malloc significantly raises the bar for
successful exploitation.


========================================================================
Inter-Process Vulnerabilities
========================================================================

Although we focused our audit on local and remote vulnerabilities,
nevertheless we identified four classes of common inter-process
vulnerabilities in OpenSMTPD:

- Out-of-bounds memory read: one process X receives a specific type of
  structure (or structured data) from another process Y, but does not
  check that process Y actually sent enough data; or, checks are
  performed, but incorrectly (e.g., because of an integer-wrap).

- Indirect information leak: if such an out-of-bounds memory read
  survives (i.e., X does not segfault), and if the partial structure
  received by X is sent back to Y as a complete structure, information
  from the memory of process X is leaked to process Y.

- Direct information leak: a structure sent by one process to another
  process contains uninitialized fields (e.g., union fields, or large
  string buffers that are only partially strlcpy()ed to), thus leaking
  information from the memory of the sending process to the receiving
  process.

- Out-of-bounds memory write: one process receives data from another
  process and copies it into a buffer without checking that it actually
  fits; or, a structure is received and its contents (e.g., size fields)
  are trusted without checks.

------------------------------------------------------------------------

In parent_imsg(), case IMSG_LKA_OPEN_FORWARD:

 169 static void
 170 parent_imsg(struct mproc *p, struct imsg *imsg)
 171 {
 172         struct forward_req      *fwreq;
 ...
 185                 case IMSG_LKA_OPEN_FORWARD:
 186                         fwreq = imsg->data;
 ...
 196                         m_compose(p, IMSG_LKA_OPEN_FORWARD, 0, 0, fd,
 197                             fwreq, sizeof *fwreq);

- Indirect information leak: fwreq.

------------------------------------------------------------------------

In queue_imsg(), case IMSG_SCHED_ENVELOPE_BOUNCE:

 64 static void
 65 queue_imsg(struct mproc *p, struct imsg *imsg)
 66 {
 ..
 68         struct bounce_req_msg   *req_bounce;
 ..
238                 case IMSG_SCHED_ENVELOPE_BOUNCE:
239                         req_bounce = imsg->data;
...
250                         queue_bounce(&evp, &req_bounce->bounce);
...
512 static void
513 queue_bounce(struct envelope *e, struct delivery_bounce *d)
514 {
515         struct envelope b;
...
519         b.agent.bounce = *d;
...
543                 m_create(p_scheduler, IMSG_QUEUE_ENVELOPE_SUBMIT, 0, 0, -1);
544                 m_add_envelope(p_scheduler, &b);
545                 m_close(p_scheduler);

- Indirect information leak: req_bounce->bounce.

------------------------------------------------------------------------

In control_imsg(), cases IMSG_STAT_INCREMENT, IMSG_STAT_DECREMENT,
IMSG_STAT_SET:

 82 static void
 83 control_imsg(struct mproc *p, struct imsg *imsg)
 84 {
 ..
 86         struct stat_value        val;
 87         struct msg               m;
 88         const char              *key;
 89         const void              *data;
 90         size_t                   sz;
 ..
165         case IMSG_STAT_SET:
166                 m_msg(&m, imsg);
167                 m_get_string(&m, &key);
168                 m_get_data(&m, &data, &sz);
169                 m_end(&m);
170                 memmove(&val, data, sz);

- Out-of-bounds memory write (stack-based buffer overflow): in the call
  to memmove(), the sz returned by m_get_data() is blindly trusted to be
  equal to the size of the stack-based val structure (CVE-2015-ABCD).

------------------------------------------------------------------------

In mda_imsg(), case IMSG_MDA_LOOKUP_USERINFO:

114 void
115 mda_imsg(struct mproc *p, struct imsg *imsg)
116 {
...
124         const void              *data;
...
127         size_t                   sz;
...
134                 case IMSG_MDA_LOOKUP_USERINFO:
135                         m_msg(&m, imsg);
136                         m_get_id(&m, &reqid);
137                         m_get_int(&m, (int *)&status);
138                         if (status == LKA_OK)
139                                 m_get_data(&m, &data, &sz);
140                         m_end(&m);
...
144                         if (status == LKA_TEMPFAIL)
...
148                         else if (status == LKA_PERMFAIL)
...
152                         else {
153                                 memmove(&u->userinfo, data, sz);

- Out-of-bounds memory write (heap-based buffer overflow): in the call
  to memmove(), the sz returned by m_get_data() is blindly trusted to be
  equal to the size of the heap-based u->userinfo structure
  (CVE-2015-ABCD).

------------------------------------------------------------------------

In mta_start_tls():

1501 static void
1502 mta_start_tls(struct mta_session *s)
1503 {
1504         struct ca_cert_req_msg  req_ca_cert;
1505         const char             *certname;
1506
1507         if (s->relay->pki_name)
1508                 certname = s->relay->pki_name;
1509         else
1510                 certname = s->helo;
1511
1512         req_ca_cert.reqid = s->id;
1513         (void)strlcpy(req_ca_cert.name, certname, sizeof req_ca_cert.name);
1514         m_compose(p_lka, IMSG_MTA_SSL_INIT, 0, 0, -1,
1515             &req_ca_cert, sizeof(req_ca_cert));

- Direct information leak: req_ca_cert.name is not fully initialized by
  strlcpy() (unlike strncpy(), strlcpy() does not fill its destination
  buffer with additional null-bytes), and therefore still contains
  sensitive information from the stack.

------------------------------------------------------------------------

In mta_session_imsg(), case IMSG_MTA_SSL_INIT:

 253         struct ca_cert_resp_msg *resp_ca_cert;
 ...
 314         case IMSG_MTA_SSL_INIT:
 315                 resp_ca_cert = imsg->data;
 ...
 336                 resp_ca_cert = xmemdup(imsg->data, sizeof *resp_ca_cert, "mta:ca_cert");
 337                 resp_ca_cert->cert = xstrdup((char *)imsg->data +
 338                     sizeof *resp_ca_cert, "mta:ca_cert");
 ...
 343                 ssl = ssl_mta_init(pkiname,
 344                     resp_ca_cert->cert, resp_ca_cert->cert_len);
 ...
 349                 explicit_bzero(resp_ca_cert->cert, resp_ca_cert->cert_len);

- Out-of-bounds memory read: resp_ca_cert.

- Out-of-bounds memory read: the string passed to xstrdup() is not
  guaranteed to be null-terminated.

- Out-of-bounds memory read: in the call to ssl_mta_init(),
  resp_ca_cert->cert_len is blindly trusted to be equal to
  resp_ca_cert->cert's xstrdup()ed length.

- Out-of-bounds memory write: in the call to explicit_bzero(),
  resp_ca_cert->cert_len is blindly trusted to be equal to
  resp_ca_cert->cert's xstrdup()ed length (CVE-2015-ABCD).

------------------------------------------------------------------------

In mta_session_imsg(), case IMSG_MTA_SSL_VERIFY:

 252         struct ca_vrfy_resp_msg *resp_ca_vrfy;
 ...
 354         case IMSG_MTA_SSL_VERIFY:
 355                 resp_ca_vrfy = imsg->data;
 356                 s = mta_tree_pop(&wait_ssl_verify, resp_ca_vrfy->reqid);
 ...
 360                 if (resp_ca_vrfy->status == CA_OK)

- Out-of-bounds memory read: resp_ca_vrfy.

------------------------------------------------------------------------

In smtp_session_imsg(), case IMSG_SMTP_SSL_INIT:

 551         struct ca_cert_resp_msg         *resp_ca_cert;
 ...
 831         case IMSG_SMTP_SSL_INIT:
 832                 resp_ca_cert = imsg->data;
 ...
 842                 resp_ca_cert = xmemdup(imsg->data, sizeof *resp_ca_cert, "smtp:ca_cert");
 ...
 845                 resp_ca_cert->cert = xstrdup((char *)imsg->data +
 846                     sizeof *resp_ca_cert, "smtp:ca_cert");
 ...
 861                 explicit_bzero(resp_ca_cert->cert, resp_ca_cert->cert_len);

- Out-of-bounds memory read: resp_ca_cert.

- Out-of-bounds memory read: the string passed to xstrdup() is not
  guaranteed to be null-terminated.

- Out-of-bounds memory write: in the call to explicit_bzero(),
  resp_ca_cert->cert_len is blindly trusted to be equal to
  resp_ca_cert->cert's xstrdup()ed length (CVE-2015-ABCD).

------------------------------------------------------------------------

In smtp_session_imsg(), case IMSG_SMTP_SSL_VERIFY:

 552         struct ca_vrfy_resp_msg         *resp_ca_vrfy;
 ...
 866         case IMSG_SMTP_SSL_VERIFY:
 867                 resp_ca_vrfy = imsg->data;
 868                 s = tree_xpop(&wait_ssl_verify, resp_ca_vrfy->reqid);
 869
 870                 if (resp_ca_vrfy->status == CA_OK)

- Out-of-bounds memory read: resp_ca_vrfy.

------------------------------------------------------------------------

In smtp_mfa_response() and smtp_io(), cases IMSG_SMTP_REQ_CONNECT and
IO_LOWAT, respectively:

 888 static void
 889 smtp_mfa_response(struct smtp_session *s, int msg, int status, uint32_t code,
 890     const char *line)
 891 {
 892         struct ca_cert_req_msg           req_ca_cert;
 ...
 905         case IMSG_SMTP_REQ_CONNECT:
 ...
 915                         if (s->listener->pki_name[0])
 916                                 (void)strlcpy(req_ca_cert.name, s->listener->pki_name,
 917                                     sizeof req_ca_cert.name);
 918                         else
 919                                 (void)strlcpy(req_ca_cert.name, s->smtpname,
 920                                     sizeof req_ca_cert.name);
 921                         m_compose(p_lka, IMSG_SMTP_SSL_INIT, 0, 0, -1,
 922                             &req_ca_cert, sizeof(req_ca_cert));

- Direct information leak: req_ca_cert.name is not fully initialized by
  strlcpy(), and therefore still contains sensitive information from the
  stack.

------------------------------------------------------------------------

In lka_imsg(), case IMSG_{SMTP,MTA}_SSL_INIT:

struct ca_cert_resp_msg {
        uint64_t                reqid;
        enum ca_resp_status     status;
        char                   *cert;
        off_t                   cert_len;
};

 63 static void
 64 lka_imsg(struct mproc *p, struct imsg *imsg)
 65 {
 ..
 75         struct ca_cert_resp_msg          resp_ca_cert;
 ..
126                 case IMSG_SMTP_SSL_INIT:
127                         req_ca_cert = imsg->data;
128                         resp_ca_cert.reqid = req_ca_cert->reqid;
...
133                         if (pki == NULL) {
134                                 resp_ca_cert.status = CA_FAIL;
135                                 m_compose(p, IMSG_SMTP_SSL_INIT, 0, 0, -1, &resp_ca_cert,
136                                     sizeof(resp_ca_cert));
137                                 return;
138                         }

- Out-of-bounds memory read: req_ca_cert.

- Direct information leak: resp_ca_cert's cert and cert_len fields.

------------------------------------------------------------------------

In ca_imsg(), case IMSG_CA_PRIV{ENC,DEC}:

292                 case IMSG_CA_PRIVENC:
293                 case IMSG_CA_PRIVDEC:
294                         m_msg(&m, imsg);
295                         m_get_id(&m, &id);
296                         m_get_string(&m, &pkiname);
297                         m_get_data(&m, &from, &flen);
298                         m_get_size(&m, &tlen);
299                         m_get_size(&m, &padding);
300                         m_end(&m);
...
307                         if ((to = calloc(1, tlen)) == NULL)
308                                 fatalx("ca_imsg: calloc");
309
310                         switch (imsg->hdr.type) {
311                         case IMSG_CA_PRIVENC:
312                                 ret = RSA_private_encrypt(flen, from, to, rsa,
313                                     padding);
314                                 break;
315                         case IMSG_CA_PRIVDEC:
316                                 ret = RSA_private_decrypt(flen, from, to, rsa,
317                                     padding);
318                                 break;
319                         }

- Out-of-bounds memory write (heap-based buffer overflow): in the call
  to RSA_private_{enc,dec}rypt(), the size (tlen) of the destination
  buffer (to) is blindly trusted to be equal to RSA_size(rsa)
  (CVE-2015-ABCD).

------------------------------------------------------------------------

In m_get_typed_sized():

493 static inline void
494 m_get_typed_sized(struct msg *m, uint8_t type, const void **dst, size_t *sz)
495 {
496         if (m->pos + 1 + sizeof(*sz) > m->end)
497                 m_error("msg too short");
498         if (*m->pos != type)
499                 m_error("msg bad type");
500         memmove(sz, m->pos + 1, sizeof(*sz));
501         m->pos += sizeof(sz) + 1;
502         if (m->pos + *sz > m->end)
503                 m_error("msg too short");
504         *dst = m->pos;
505         m->pos += *sz;
506 }

- Out-of-bounds memory read: *sz, the amount of data allegedly received,
  is read directly from the wire and sanity-checked, but large *sz
  values can integer-wrap the check.

------------------------------------------------------------------------

In m_get_sockaddr():

705 void
706 m_get_sockaddr(struct msg *m, struct sockaddr *sa)
707 {
708         size_t           s;
709         const void      *d;
710
711         m_get_typed_sized(m, M_SOCKADDR, &d, &s);
712         memmove(sa, d, s);
713 }

- Out-of-bounds memory write (buffer overflow): in the call to
  memmove(), the size s of the data d returned by m_get_typed_sized() is
  blindly trusted to be equal to the size of the sockaddr structure sa
  (CVE-2015-ABCD).


========================================================================
Miscellaneous Bugs
========================================================================

------------------------------------------------------------------------

In mta_imsg(), case IMSG_CTL_RESUME_ROUTE, if u64 is 0 ("resuming all
routes"), mta_route_unref() may eventually free() route, which is then
used-after-free by SPLAY_NEXT() in SPLAY_FOREACH() (there is a SAFE
version of most FOREACH macros, but no SPLAY_FOREACH_SAFE()):

 419                 case IMSG_CTL_RESUME_ROUTE:
 420                         u64 = *((uint64_t *)imsg->data);
 ...
 426                         SPLAY_FOREACH(route, mta_route_tree, &routes) {
 427                                 if (u64 && route->id != u64)
 428                                         continue;
 429
 430                                 if (route->flags & ROUTE_DISABLED) {
 ...
 441                                         mta_route_unref(route); /* from mta_route_disable */
 442                                 }
 443
 444                                 if (u64)
 445                                         break;
 446                         }
 447                         return;

------------------------------------------------------------------------

In parent_sig_handler(), the cause pointer should always be initialized
to NULL before the calls to asprintf(), and the return value of these
calls should be checked (on OpenBSD, asprintf() will always reset the
cause pointer to NULL in case of a failure, but this behavior is
implementation-dependent):

 351 static void
 352 parent_sig_handler(int sig, short event, void *p)
 353 {
 ...
 357         char            *cause;
 ...
 365                 do {
 366                         pid = waitpid(-1, &status, WNOHANG);
 ...
 371                         if (WIFSIGNALED(status)) {
 ...
 373                                 asprintf(&cause, "terminated; signal %d",
 374                                     WTERMSIG(status));
 375                         } else if (WIFEXITED(status)) {
 376                                 if (WEXITSTATUS(status) != 0) {
 ...
 378                                         asprintf(&cause, "exited abnormally");
 379                                 } else
 380                                         asprintf(&cause, "exited okay");
 381                         } else
 382                                 fatalx("smtpd: unexpected cause of SIGCHLD");
 ...
 442                         free(cause);
 443                 } while (pid > 0 || (pid == -1 && errno == EINTR));

------------------------------------------------------------------------

Code similar to the following appears several times in OpenSMTPD:

 979         (void)strlcpy(sfn, "/tmp/smtpd.out.XXXXXXXXXXX", sizeof(sfn));
 980         omode = umask(7077);
 981         allout = mkstemp(sfn);
 982         umask(omode);
 983         if (allout < 0) {
 ...
 991                 return;
 992         }
 993         unlink(sfn);

But 7077 is decimal, not octal; in octal, 7077 is 015645. Luckily, the
call to mkstemp() that always follows uses mode 0600, which results in
the final mode 0000 (0600 & ~015645). This is not a security issue,
because these permissions are even more restrictive than those
originally intended.

------------------------------------------------------------------------

In do_show_queue(), chdir(".") should rather be chdir("/"), because the
current working directory may be outside the chroot tree:

 652                 if (chroot(PATH_SPOOL) == -1 || chdir(".") == -1)
 653                         err(1, "%s", PATH_SPOOL);

However, this is not a security issue either: do_show_queue() is an
smtpctl functionality, only root is allowed to run it, and all
subsequent filesystem accesses begin with '/' anyway.


========================================================================
Acknowledgments
========================================================================

We would like to thank OpenSMTPD's developers for their cooperation,
professional work, and minute attention to every detail in our audit
report.

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.