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

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:

Fetchmail version 6.3.9 enabled "all SSL workarounds" (SSL_OP_ALL) which contains a switch to disable a countermeasure against certain attacks against block ciphers that permit guessing the initialization vectors, providing that an attacker can make the application (fetchmail) encrypt some data for him -- which is not easily the case.

Stream ciphers (such as RC4) are unaffected.

Credits to Apple Product Security for reporting this.

ge 6.3.9 lt 6.3.22

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:

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