Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777

[Michael Samuel <mik () miknet net>]

On 12 March 2015 at 15:43, Kurt Seifried <kseifried () redhat com> wrote:
> If your SSL/TLS implementation accepts expired certs as being ok, then
> you have a problem.

Sure thing, test for it then if you like.  Just install an expired
cert on a test
server and connect.  But if I logged it against a RedHat product, I'd put it
as a bug, not security issue.

> > > 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?
>
> That's a real world bug. Logic error "trust properly signed cert" vs.
> "trust specific CA signed cert".

Ok, but if somebody's implemented this feature they've gone well beying
the point of not verifying certificates at all, which is what pretty much every
program I tested that ships with RHEL did until I logged bugs against them.

Apache still doesn't validate certificates for backend connections in RHEL
(mod_proxy).

> Uhm. Did you not look at any of the cve.mitre.org links I sent? These
> are incredibly common failures. Hint: if some class of bug has a bunch
> of CVE's you can multiply it by 100 or more for the number of affected
> real world cases (and that's in English software alone).

If you think they're common, ask your dev teams test for them before
shipping.

> Anyways I think we're sufficiently off topic now.

I think this is an important discussion to have, and I don't think we're at all
off topic (for the list or thread).  I know TLS is hard, but we don't have to
default to snake-oil bad.

Regards,
  Michael