An unintended cleartext issue exists in Go before 1.8.4 and 1.9.x before 1.9.1. RFC 4954 requires that, during SMTP, the PLAIN auth scheme…
mitre·CWE-319·Published 2017-10-05
An unintended cleartext issue exists in Go before 1.8.4 and 1.9.x before 1.9.1. RFC 4954 requires that, during SMTP, the PLAIN auth scheme must only be used on network connections secured with TLS. The original implementation of smtp.PlainAuth in Go 1.0 enforced this requirement, and it was documented to do so. In 2013, upstream issue #5184, this was changed so that the server may decide whether PLAIN is acceptable. The result is that if you set up a man-in-the-middle SMTP server that doesn't advertise STARTTLS and does advertise that PLAIN auth is OK, the smtp.PlainAuth implementation sends the username and password.
An unintended cleartext issue exists in Go before 1.8.4 and 1.9.x before 1.9.1. RFC 4954 requires that, during SMTP, the PLAIN auth scheme must only be used on network connections secured with TLS. The original implementation of smtp.PlainAuth in Go 1.0 enforced this requirement, and it was documented to do so. In 2013, upstream issue #5184, this was changed so that the server may decide whether PLAIN is acceptable. The result is that if you set up a man-in-the-middle SMTP server that doesn't advertise STARTTLS and does advertise that PLAIN auth is OK, the smtp.PlainAuth implementation sends the username and password.
SMTP clients using net/smtp can use the PLAIN authentication scheme on network connections not secured with TLS, exposing passwords to man-in-the-middle SMTP servers.
Existe un problema de texto en claro no planeado en la versión 1.8.4 y versiones 1.9.x anteriores a la 1.9.4 de Go. La RFC 4954 requiere que durante la autenticación SMTP, el esquema de autenticación PLAIN solo se use en conexiones de red protegidas con TLS. La implementación original de smtp.PlainAuth en Go 1.0 aseguraba el cumplimiento de este requisito y se documentó que esto se llevase a cabo. En 2013, problema upstream #5184, esto se modificó para que el servidor pudiera decidir si se acepta PLAIN. El resultado es que si un usuario crea un servidor SMTP Man-in-the-Middle (MitM) que no anuncia STARTTLS pero sí anuncia que la autenticación PLAIN es OK, la implementación smtp.PlainAuth envía el nombre de usuario y contraseña.
| Version | Type | Source | Base | Exp | Impact | Vector |
|---|---|---|---|---|---|---|
| 2.0 | Primary | NVD | 4.3 | 8.6 | 2.9 | AV:N/AC:M/Au:N/C:P/I:N/A:N |
| 3.0 | Primary | NVD | 5.9 | 2.2 | 3.6 | CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N |