FreshPorts - VuXML

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.

< 6.3.6

Matthias Andree reports:

fetchmail will generate warning messages in certain circumstances (for instance, when leaving oversized messages on the server or login to the upstream fails) and send them to the local postmaster or the user running it.

If this warning message is then refused by the SMTP listener that fetchmail is forwarding the message to, fetchmail crashes and does not collect further messages until it is restarted.

ge 4.6.8 lt 6.3.8_4

Matthias Andree reports:

Gunter Nau reported fetchmail crashing on some messages; further debugging by Petr Uzel and Petr Cerny at Novell/SUSE Czech Republic dug up that this happened when fetchmail was trying to print, in -v -v verbose level, headers exceeding 2048 bytes. In this situation, fetchmail would resize the buffer and fill in further parts of the message, but forget to reinitialize its va_list typed source pointer, thus reading data from a garbage address found on the stack at addresses above the function arguments the caller passed in; usually that would be the caller's stack frame.

< 6.3.8_6

Matthias Andree reports:

When a log message exceeds c. 2 kByte in size, for instance, with very long header contents, and depending on verbosity option, fetchmail can crash or misreport each first log message that requires a buffer reallocation.

< 6.3.9

ge 6.3.17 lt 6.4.20

Matthias Andree reports:

Moxie Marlinspike demonstrated in July 2009 that some CAs would sign certificates that contain embedded NUL characters in the Common Name or subjectAltName fields of ITU-T X.509 certificates.

Applications that would treat such X.509 strings as NUL-terminated C strings (rather than strings that contain an explicit length field) would only check the part up to and excluding the NUL character, so that certificate names such as www.good.example\0www.bad.example.com would be mistaken as a certificate name for www.good.example. fetchmail also had this design and implementation flaw.

< 6.3.11

Fetchmail developer Matthias Andree reported a vulnerability that allows remote attackers to crash the application when it is runs in verbose mode.

Fetchmail before release 6.3.17 did not properly sanitize external input (mail headers and UID). When a multi-character locale (such as UTF-8) was in use, this could cause memory exhaustion and thus a denial of service.

ge 4.6.3 le 6.3.16

Matthias Andree reports:

With NTLM support enabled, fetchmail might mistake a server-side error message during NTLM protocol exchange for protocol data, leading to a SIGSEGV.

Also, with a carefully crafted NTLM challenge, a malicious server might cause fetchmail to read from a bad memory location, betraying confidential data. It is deemed hard, although not impossible, to steal other accounts' data.

ge 5.0.8 lt 6.3.21_1

Matthias Andree reports:

The POP3 standard, currently RFC-1939, has specified an optional, MD5-based authentication scheme called "APOP" which no longer should be considered secure.

Additionally, fetchmail's POP3 client implementation has been validating the APOP challenge too lightly and accepted random garbage as a POP3 server's APOP challenge. This made it easier than necessary for man-in-the-middle attackers to retrieve by several probing and guessing the first three characters of the APOP secret, bringing brute forcing the remaining characters well within reach.

< 6.3.8

Matthias Andree reports:

2008-06-24 1.2 also fixed issue in report_complete (reported by Petr Uzel)

< 6.3.8_7

Problem:

In certain circumstances, fetchmail 6.4.21 and older would not encrypt the session using STARTTLS/STLS, and might not have cleared session state across the TLS negotiation.

< 6.4.22.r1

Matthias Andree reports:

Fetchmail version 5.9.9 introduced STLS support for POP3, version 6.0.0 added STARTTLS for IMAP. However, the actual S(TART)TLS-initiated in-band SSL/TLS negotiation was not guarded by a timeout.

Depending on the operating system defaults as to TCP stream keepalive mode, fetchmail hangs in excess of one week after sending STARTTLS were observed if the connection failed without notifying the operating system, for instance, through network outages or hard server crashes.

A malicious server that does not respond, at the network level, after acknowledging fetchmail's STARTTLS or STLS request, can hold fetchmail in this protocol state, and thus render fetchmail unable to complete the poll, or proceed to the next server, effecting a denial of service.

SSL-wrapped mode on dedicated ports was unaffected by this problem, so can be used as a workaround.

< 6.3.20