[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B99223E.7030608@stafford.uklinux.net>
Date: Thu, 11 Mar 2010 17:02:54 +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:
> Brian Stafford wrote:
>
>> [...]
>> I find myself coming back to RFC 2818 being a reasonable choice since it
>> is flexible and (almost) clear, and since HTTPS, as a major user of TLS,
>> is, I assume, well analysed for security implications wrt certificate
>> validation.
>>
>
> More fun:
> https://bugzilla.mozilla.org/show_bug.cgi?id=159483
>
Aargh! I'm half way down this discussion and already I'd prefer to
stick needless in my eyes. So far though consensus seems to be RFC 2818
rules for wildcards. I notice some of the test patterns suggested would
not work in libESMTP as it stands.
>
>> Is it the case that for STARTTLS in SMTP what we are really interested
>> in is encrypting the data on the wire and authentication is only of
>> secondary importance?
>>
>
> Encryption without authentication makes you prone to MITM.
>
Indeed.
>
>> Do we know what the best current practice is
>> among CAs when it comes to issuing certificates for STARTTLS?
>>
>
> The most common implementation is to just allow the simple form
> *.something so I'd assume that other patterns are rare in the wild.
> The last commenter in the aforementioned Mozilla bug says that
> *.*.appspot.com is actually used by Google though.
>
> Anyways, the matching function in libesmtp certainly is good enough.
> I was just surprised that wildcards at the right hand side are
> allowed. What about the actual patch I sent though? :-)
>
I'm happy that the patch jumps through the right hoops though I'm rather
out of touch with the OpenSSL APIs these days so there is a certain
element of trust here :-)
However I did realise there is another problem with the wildcard match.
Currently match_component() just steps over text when it sees the '*',
however it should really be like a character class i.e. the RE
'[-A-Za-z0-9]*'. Currently * will match any old junk in the hostname
including punctuation and control codes which gives a possibility of
attacking a system using specially crafted hostnames. I shall modify
match_component() to deal with this and other issues that may be
relevant, after I've waded through the rest of the mozilla thread.
> cu
> Ludwig
>
>
Rergards
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.
