3 ms·

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

5 points by based2 7y ago

based2 7y ago
https://github.com/OpenSMTPD/OpenSMTPD/releases https://github.com/OpenSMTPD/OpenSMTPD/releases
cnst 7y ago
Exploitable remotely in the default OpenBSD install.
- asveikau 7y ago
  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 7y ago
    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 7y ago
      > 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 7y ago
        > 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.
deleted 7y ago
[deleted]

5 points by based2 7y ago

based2 7y ago

https://github.com/OpenSMTPD/OpenSMTPD/releases https://github.com/OpenSMTPD/OpenSMTPD/releases

cnst 7y ago

Exploitable remotely in the default OpenBSD install.

asveikau 7y ago
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 7y ago
  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 7y ago
    > 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 7y ago
      > 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.

deleted 7y ago

[deleted]