FreshPorts - VuXML

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

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

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

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:

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

< 6.3.8_7

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:

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:

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