fetchmail-6.3.18 (not yet released):
+# SECURITY IMPROVEMENTS TO DEFANG X.509 CERTIFICATE ABUSE
+* Fetchmail now only accepts wildcard certificate common names and subject
+ alternative names if they start with "*.". Previous versions would accept
+ wildcards even if no period followed immediately.
+* Fetchmail now disallows wildcards in certificates to match domain literals
+ (such as 10.9.8.7), or wildcards in domain literals ("*.168.23.23").
+ The test is overly picky and triggers if the pattern (after skipping the
+ initial wildcard "*") or domain consist solely of digits and dots and matches
+ more than needed.
+
# BUG FIXES
* Fetchmail would warn about insecure SSL/TLS connections even if a matching
--sslfingerprint was specified. This is an omission from an SSL usability
credentials. This avoids getting servers such as Exchange 2007 wedged if
GSSAPI authentication fails. Reported by Patrick Rynhart, Debian Bug #568455,
and Alan Murrell, to the fetchmail-users list.
-* Fetchmail now only accepts wildcard certificate common names and subject
- alternative names if they start with "*.". Previous versions would accept
- wildcards even if no period followed immediately.
# CHANGES
* When encountering incorrect headers, fetchmail will refer to the bad-header
* The only place where a wildcard is allowed is in the leftmost
* position of p1. */
static int name_match(const char *p1, const char *p2) {
- if (p1[0] == '*' && p1[1] == '.') {
+ const char *const dom = "0123456789.";
+ int wildcard_ok = 1;
+
+ /* blank patterns never match */
+ if (p1[0] == '\0')
+ return 0;
+
+ /* disallow wildcards in certificates for domain literals
+ * (10.9.8.7-like) */
+ if (strspn(p1+(*p1 == '*' ? 1 : 0), dom) == strlen(p1))
+ wildcard_ok = 0;
+
+ /* disallow wildcards for domain literals */
+ if (strspn(p2, dom) == strlen(p2))
+ wildcard_ok = 0;
+
+ if (wildcard_ok && p1[0] == '*' && p1[1] == '.') {
size_t l1, l2;
++p1;