Date: Wed, 11 Mar 2015 18:07:53 -0600 From: Kurt Seifried <kseifried@...hat.com> To: oss-security@...ts.openwall.com Subject: Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 On 03/11/2015 05:44 PM, Michael Samuel wrote: > On 12 March 2015 at 02:48, Kurt Seifried <kseifried@...hat.com> wrote: > >> Much like /tmp issues the solution that will save us is not to fix every >> /tmp issue but rather do more intelligent things like poly instantiated >> tmp or systemd per process tmp. Sadly I don't see such an easy >> possibility with TLS/SSL, but if we have a decent test >> framework/reproduction ability it will make finding, fixing and >> verifying these things a whole lot easier long term. > > You can test for the common bugs extremely easily - you need two types of > bogus certificate installed on the server: > - A completely untrusted (eg. self-signed) certificate > - A certificate signed by a trusted authority but for the wrong hostname 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? What about a certificate signed for the correct hostname by a system trusted CA? (some apps are supposed to only trust a specific CA). These are all very common issues. But those would never happen right? http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=expired+certificate 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? That never happens right? http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=invalid+certificate And then on the more complicated/operational side: What about intermediate certificate issues/chains/etc? What about weak protocols? What about weak ciphers? What about weak keys? What about specifically bad keys (https://wiki.debian.org/SSLkeys)? What about overly broad certs used by interceptors (like *.com, *.*) What about checking certificate constraints? http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=intermediate+certificate http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=certificate+constraints FREAK, etc. And those are just off the top of my head. There's a whole deep rabbit hole full of angry ... things. I don't know because I don't want to stick my head into it. Also we'll conveniently ignore the CA issues. Diginotar et al. Properly testing this even to a half hearted degree is very non trivial. 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. > 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 > 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. > Regards, > Michael > -- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
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.