Re: CVE Request: libesmtp does not check NULL bytes in commonName

[Brian Stafford <brian () stafford uklinux net>]

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 'foo.bar.*' which is rather weird.
>   
I've been reviewing match_domain() with a view to how it conforms to RFC 
2459 and RFC 2818 section 3.1.  Unfortunately, the relevant text is 
rather less rigourous than it might be so some further input might be 
useful.

The text in RFC 2459 is

  Finally, the semantics of subject alternative names that include
  wildcard characters (e.g., as a placeholder for a set of names) are
  not addressed by this specification.  Applications with specific
  requirements may use such names but shall define the semantics.

which is fair enough.  The text from RFC 2818 defining the semantics is

  Matching is performed using the matching rules specified by
  [RFC2459].  If more than one identity of a given type is present in
  the certificate (e.g., more than one dNSName name, a match in any one
  of the set is considered acceptable.) Names may contain the wildcard
  character * which is considered to match any single domain name
  component or component fragment. E.g., *.a.com matches foo.a.com but
  not bar.foo.a.com. f*.com matches foo.com but not bar.com.

My interpretation, in the absense of clarification or an update to RFC 
2818, follows.

RFC 2818 does not constrain which domain name components may contain 
wildcards. Names such as *.bar.com, foo.*.com and foo.bar.* 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.

Currently match_component() accepts a wildcard character * only in the 
final position of the component pattern.  However RFC 2818 does not 
actually state that the wildcard is so constrained, although the 
examples show only this case.  The text from RFC 2818 permits, albeit 
not explicitly, component patterns interspersed with wildcards, for 
example, 'foo*bar', '*bar*', 'foo*bar*baz' etc.  I am unclear as to the 
author's original intent, nevertheless I feel that to correctly 
implement RFC 2818 libESMTP's match_component() should permit 
comparisons where the wildcard may appear multiple times in the 
component pattern (as is permitted in fnmatch(3) for example).

RFC 2818 has INFORMATIONAL status so perhaps there is some latitude 
here.  On the other hand, while an INFORMATIONAL RFC is not normative 
there is no other normative text I am aware of so I feel that RFC 2818 
must be assumed to be normative in this context.

regards
Brian