
LPE and RCE in OpenSMTPD's default install (CVE-2020-8794) - based2
https://www.openwall.com/lists/oss-security/2020/02/24/5
======
based2
[https://github.com/OpenSMTPD/OpenSMTPD/releases](https://github.com/OpenSMTPD/OpenSMTPD/releases)

------
cnst
Exploitable remotely in the default OpenBSD install.

~~~
asveikau
The article says opensmtpd only binds to localhost by default, so you have to
configure it to take mail from outside to be remotely exploitable.

That said, this kinda sucks, 2nd remote root exploit on this daemon this year,
and it's only February. Good that they are fixing them I guess, but I hope
they take it as a hint to make some design changes in how much code runs as
root.

~~~
cnst
It's a bug in the client part of OpenSMTPD, so, it is still remotely
exploitable in the default install, it's just that the user has to attempt
sending some mail out towards the infrastructure controlled by the attacker
(could be a malicious WiFi SMTP interceptor, for example).

If you do have the server mode enabled on non-localhost, then you can initiate
this client mode (by means of a bounce) yourself remotely, without the need
for any local user to do anything.

They'll be dropping the exploit code tomorrow on Wed, 26th!

~~~
asveikau
> it's just that the user has to attempt sending some mail out towards the
> infrastructure controlled by the attacker (could be a malicious WiFi SMTP
> interceptor, for example).

I would not personally consider that remotely exploitable. A local user needs
to initiate something first. As far as your parenthetical example: it's not at
all common or reasonable for a user to not configure their local-only mail
server and then use it to send remote mail. They'd use a properly configured
remote server for that.

It's very bad, don't get me wrong. But if you leave a box on the network and
don't touch the configuration at all, you won't see it exploited from somebody
who can't log into the machine.

~~~
cnst
> As far as your parenthetical example: it's not at all common or reasonable
> for a user to not configure their local-only mail server and then use it to
> send remote mail. They'd use a properly configured remote server for that.

I have no idea what makes you think that; you're probably coming from the
Linux land where the mail command doesn't work by default? On non-Linux
systems, local mail server is normally activated, and is fully capable of
sending mail to the remote hosts by default, with a spool and all. The
/usr/bin/mail just works, as well as sending mail from anything like mutt and
friends, without any configuration (other than specifying an outgoing FROM
hostname to not a non-existent one). Unless the outgoing SMTP port is blocked
— which it's not on many networks for advanced users — there's nothing to
configure.

