[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B985203.80907@stafford.uklinux.net>
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
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.
