Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Mar 2010 14:42:32 +0100
From: Ludwig Nussel <>
Cc: Brian Stafford <>,,
Subject: Re: CVE Request: libesmtp does not check NULL bytes in commonName

Brian Stafford wrote:
> Ludwig Nussel wrote:
> > The attached patch includes the patch from Debian. However, the
> > match_domain() function probably should be rewritten anyways I
> > guess. It matches patters such as '*' which is rather weird.
> [...]
> RFC 2818 does not constrain which domain name components may contain 
> wildcards. Names such as *, foo.*.com and* are 
> therefore all valid despite the latter two cases appearing 
> unconventional.  The examples from RFC 2818 show wildcards only in the 
> leading domain name components. Examples are neither normative nor 
> exhaustive and may not therefore imply constraints or extensions of a 
> standard's normative text. Comparison bugs aside, I believe that 
> libESMTP's behaviour correctly implements RFC 2818 in this respect.

Hmm. Yes, RFC 2818 could be interpretet that way. RFCs 2595 (IMAP),
4642 (NNTP) and 4513 (LDAP) restrict wildcards to the leftmost
component. The LDAP one doesn't allow wildcards in CN's though and
none of them explicitly disallows use of the CN if a subjAltname is
present. RFC 3207 (SMTP) doesn't tell how matching should be
performed. perl-IO-Socket therefore doesn't allow wildcards for
smtp. perl-IO-Socket has the most flexible implementation I've seen
so far but intentionally only supports one wildcard at the leftmost
side. What a mess.


 (o_   Ludwig Nussel
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.