[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACYkhxgfP37Jp9vD7WMDxxdBDQVQ6nSGNX1a+BMPVxjY111QUw@mail.gmail.com>
Date: Thu, 12 Mar 2015 14:03:34 +1100
From: Michael Samuel <mik@...net.net>
To: oss-security@...ts.openwall.com
Subject: Re: Another Python app (rhn-setup: rhnreg_ks) not
checking hostnames in certs properly CVE-2015-1777
Hi,
On 12 March 2015 at 11:07, Kurt Seifried <kseifried@...hat.com> wrote:
>> You can test for the common bugs extremely easily - you need two types of
>
> If only it were so simple. Seriously, life would be awesome.
>
> What about expired certificates?
> What about certificates that are properly signed but not yet valid?
Sure, you could test these too, but I'd argue these are policy issues,
not security bugs.
Where is an attacker going to get the private key for an expired cert,
but be unable to
find the current one?
> What about a certificate signed for the correct hostname by a system
> trusted CA? (some apps are supposed to only trust a specific CA).
That's a policy bug too, not an easily exploitable security bug
(unless one of your
system CAs is compromised). Does RedHat actually ship anything that
does pinning?
> These are all very common issues.
Not nearly as common or exploitable as not checking the certificate at
all, of which I've
reported plenty of to RedHat and others over the past couple of years.
> But we're also dealing with bad guys right? If we assume they can man in
> the middle we have to assume they are at least semi competent (e.g. they
> know how to run Tapioca or nogotofail).
>
> So what about mangled certs that make the system go all wibbly wobbly?
Sure, but you're just making arguments for using common validation routines (as
originally proposed), which can be easily checked. Although I must admit I was
surprised by NSS being vulnerable to a variant of Bleichenbacher's
attack last year!
> And if you talk to people that actually know SSL/TLS (I just pretend to
> understand it) ... well if you've ever seen a train wreck in slow motion
> you know what it's like.
Sure thing. As mentioned earlier on list and elsewhere, almost
everything that copied
nginx s3_srvr.c session ticket code (Apache, Nginx, ...) isn't
checking the retval of
RAND_pseudo_bytes(), so you might be sending stack/heap data as the IV of your
session tickets instead of entropy. But those are bugs.
>> It's not too hard to test SSH connections in a similar manner (just regen the
>> ssh host keys after the first connection).
>
> Again if only it were so simple.
> http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ssh+key
Yes, I reported a few of those. Also we could talk about how rhev
sets up new hosts
using small block-size CBC ciphers due to the crazy java SSH library
it uses. Again,
bugs.
>> Alternatively, you could make your OpenSSL modules for various languages
>> return client ctxs that verify by default - the topic of this discussion :)
>
> Yeah, the problem is API/ABI compatibility. Again, Red Hat has to
> support software we have never seen, and will never see.
I understand that. Which is why I proposed that specific solution,
instead of the one
I prefer (what upstream python did).
Regards,
Michael
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.
