4 ms·

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 mai

by 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.

by cnst 7y ago

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.