Matthias Andree reports:
Fetchmail has had several longstanding password disclosure vulnerabilities.
- sslcertck/sslfingerprint options should have implied "sslproto tls1" in order to enforce TLS negotiation, but did not.
- Even with "sslproto tls1" in the config, fetches would go ahead in plain text if STLS/STARTTLS wasn't available (not advertised, or advertised but rejected).
- POP3 fetches could completely ignore all TLS options whether available or not because it didn't reliably issue CAPA before checking for STLS support - but CAPA is a requisite for STLS. Whether or not CAPAbilities were probed, depended on the "auth" option. (Fetchmail only tried CAPA if the auth option was not set at all, was set to gssapi, kerberos, kerberos_v4, otp, or cram-md5.)
- POP3 could fall back to using plain text passwords, even if strong authentication had been configured.
- POP2 would not complain if strong authentication or TLS had been requested.
Disclaimer: The data contained on this page is derived from the VuXML document, please refer to the the original document for copyright information. The author of portaudit makes no claim of authorship or ownership of any of the information contained herein.
If you have found a vulnerability in a FreeBSD port not listed in the database, please contact the FreeBSD Security Officer. Refer to "FreeBSD Security Information" for more information.