Bug 1151208 (CVE-2014-8164)

Summary: CVE-2014-8164 CFME: http.verify_mode = OpenSSL::SSL::VERIFY_NONE
Product: [Other] Security Response Reporter: Kurt Seifried <kseifried>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: apatters, bdunne, dajohnso, dclarizi, gmccullo, jfrey, jhenner, jprause, jrafanie, jrusnack, jvlcek, kseifried, mpovolny, obarenbo, security-response-team, xlecauch
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-30 20:28:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1151209, 1151210    
Bug Blocks: 1129011    

Description Kurt Seifried 2014-10-09 19:25:03 UTC
CloudForms: http.verify_mode = OpenSSL::SSL::VERIFY_NONE

From the email:

Ok so two main things here, firstly I would prefer to fix this all at
once, looking at the code there's a whole bunch of instances of
"http.verify_mode = OpenSSL::SSL::VERIFY_NONE" (11 or so out of 17
total calls for http.verify), so even if we fix this default one,
there would still be the 11 instances, so rather than do several fixes
and end up with multiple CVE's I'd rather do this all at once. Now as
how to fix it:

1) removing any uneeded code with respect to this SSL stuff
(apparently a few may not be needed anymore?)

2) By default change it so that we check SSL correctly, however for
backwards compatibility of existing installations, and for demos we
want to allow the old behaviour, so some switch in a config file/web
interface like "Allow self signed certs" with a warning/explanation.

3) To protect against attacks (e.g. with a self signed cert, we can't
check it properly, so a man in the middle attack is pretty easy) we
could harden it by caching the certificates the first time we see
them, and then checking against that cached copy. So in theory the
first time you access it (right after setup) is safe, we cache that,
and in future any changes would cause an alarm, basically buying us
most of what you would get by using a "Real" certificate.

So I would say #2 is mandatory, #1 is always good (removing dead code)
and #3 would be very nice to have, but really if people want security
they can buy certificates for not much money.

Comment 2 Kurt Seifried 2015-06-30 20:28:41 UTC
This has been deferred for now. One challenge is to enable certificate host name checking this customers will require a large number of valid host certificates. This is difficult for many customers due to the use of internal hosts, as such enabling host name checks by default will break many installs.

Comment 3 Jaroslav Henner 2015-11-18 11:18:02 UTC
*** Bug 1281383 has been marked as a duplicate of this bug. ***