oss-sec mailing list archives
Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777
From: Kurt Seifried <kseifried () redhat com>
Date: Wed, 11 Mar 2015 11:48:06 -0400
On 03/10/2015 08:05 PM, Michael Samuel wrote:
Hi Kurt, Your corporate pissing match with Oracle is not helpful.
I think there's probably some cultural disconnect here that is causing issues, a big part of Red Hat is "upstream first" and doing things the open source way. Let's look at who wrote PEP 466 and who he works for. Hint: it's Red Hat. We're obviously interested in fixing this, BUT we also have the challenge of fixing this without breaking any software, software which again, we haven't seen and will never see. Read the sections: Rejected alternative: just advise developers to migrate to Python 3 Rejected alternative: create and release Python 2.8 Rejected alternative: distribute the security enhancements via PyPI Rejected variant: provide a "legacy SSL infrastructure" branch Rejected variant: synchronise particular modules entirely with Python 3 Rejected variant: open ended backport policy this is non trivial stuff. However here's the cool thing. If Oracle thinks they have a good solution they can participate with upstreams, or simply try it. Build some RPMs, make them available and gather test data (e.g. we ran these test suites/apps and X percent broke/didn't break/etc.). Working code and experimental data is (almost) hugely more valuable then discussions on a mailing list. At least we'll find out what doesn't work if it doesn't work (that's the experimental data part). Personally what I'm more interested in right now is better testing/reproducers for SSL/TLS issues for the community rather then playing random whack-a-mole with specific issues (especially ones that we already have smart people working on). 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.
On 11 March 2015 at 02:56, Kurt Seifried <kseifried () redhat com> wrote:My experience is a lot of people propose a LOT of things on email lists, but when it actually comes down to them doing the work, nothing happens because quite often the people proposing the work don't have the expertise or ability to do it. oss-security@ archives are littered with such examples (e.g. the whole code audit thing).I proposed this in the context of me giving up reporting these sorts of bugs to RedHat (go search my BZ account), and frankly since you don't have the resources to perform simple tests against your main products (RHEV, Satellite, RHN), then a blanket solution seems reasonable.So it's not that I'm unwilling, I simply don't see why you need massive corporate/community buy in at this point, premature optimization and all that. Build a solution, or more than one solution and try them out, then report back to oss-security@ with what works/doesn't work. In general the best way to determine what the best solution is for a problem is to try several solutions out. Prototype code and experimental data is worth 1000 meetings.It's not a problem because nobody's looking. Holy crap, just look at Satellite 6 and tell me you think that product doesn't need more than an audit.
I am actually working on something that will hopefully provide a better solution (for values of speed and ease of fixing flaws) than a traditional audit/code fix, (I'd rather address entire classes of security flaw rather than one instance of the flaw at a time). But like all things security infinite workload delays specific projects.
Regards, Michael
-- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Attachment:
signature.asc
Description: OpenPGP digital signature
Current thread:
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777, (continued)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 Kurt Seifried (Mar 09)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 John Haxby (Mar 09)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 Kurt Seifried (Mar 09)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 John Haxby (Mar 10)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 Michael Samuel (Mar 10)
- Re: PEP-466 common compatible implementation. (was ... CVE-2015-1777) John Haxby (Mar 10)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 Kurt Seifried (Mar 10)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 John Haxby (Mar 10)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 John Haxby (Mar 10)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 Michael Samuel (Mar 10)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 Kurt Seifried (Mar 11)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 John Haxby (Mar 11)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 Kurt Seifried (Mar 11)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 Donald Stufft (Mar 11)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 Michael Samuel (Mar 11)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 Kurt Seifried (Mar 11)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 Michael Samuel (Mar 11)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 Kurt Seifried (Mar 11)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 Michael Samuel (Mar 11)
- Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 Tomas Hoger (Mar 05)