Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Mar 2010 02:14:27 +0000
From: Brian Stafford <brian@...fford.uklinux.net>
To: Ludwig Nussel <ludwig.nussel@...e.de>
CC: oss-security@...ts.openwall.com, libesmtp@...fford.uklinux.net, 
 security@...ntu.com
Subject: Re: CVE Request: libesmtp does not check NULL bytes
 in commonName

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


Powered by blists - more mailing lists

Your e-mail address:

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.