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.