net/smtp: SMTP injection via recipient addresses #21159
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Security
Milestone
(I contacted security@golang.org about this and was asked to create a public issue.)
What version of Go are you using (
go version
)?1.8.3 and 1.9beta2
What operating system and processor architecture are you using (
go env
)?darwin/amd64
What did you do?
Go's net/smtp package appears to be vulnerable to SMTP injection via recipient e-mail addresses, similar to the issues outlined in this whitepaper for other languages: http://www.mbsd.jp/Whitepaper/smtpi.pdf
Here's a quick demonstration:
Basically, if you pass an unsanitized address to address inputs, like
SendMail
,Rcpt
, orMail
(eg"recipient@example.net>\r\nDATA\r\nInjected message body\r\n.\r\nQUIT\r\n"
), it's possible to manipulate the e-mail body sent.What did you expect to see?
In the example above, net/smtp should reject the recipient address since it contains line breaks.
What did you see instead?
The message is sent to
recipient@example.net
with a message body of "Injected message body" (instead of the intended body of "Real message body").Notes
As indicated in the whitepaper, the solution for this is to disallow line breaks in the "RCPT TO" and "MAIL FROM" commands, which is also in accordance with RFC 5321. So unless you think it's the responsibility of applications to sanitize addresses (rather than in net/smtp's purview), it would be nice to see this fixed in Go's builtin net/smtp package, so things are safer by default.
If you'd like for me to put together a patch to address this, I'd be happy to try and do that.
And if it helps (and for additional context), you can see how this security issue was addressed in the Ruby ecosystem last year:
Net::SMTP
library was updated to reject any command lines with line breaks in it.The length restriction is to address the theoretical CRLF-less attack outlined in the whitepaper, but as the whitepaper's conclusion indicates:
So I'm not 100% sure about the best approach, but it seems like perhaps just rejecting line breaks in a library like net/smtp might be preferable, unless you think it's also worth enforcing the line length limits in accordance with RFC 5321.
The text was updated successfully, but these errors were encountered: