Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1151208 - (CVE-2014-8164) CVE-2014-8164 CFME: http.verify_mode = OpenSSL::SSL::VERIFY_NONE
CVE-2014-8164 CFME: http.verify_mode = OpenSSL::SSL::VERIFY_NONE
Status: CLOSED DEFERRED
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20150116,reported=2...
: Security
: 1281383 (view as bug list)
Depends On: 1151209 1151210
Blocks: 1129011
  Show dependency treegraph
 
Reported: 2014-10-09 15:25 EDT by Kurt Seifried
Modified: 2015-11-18 06:18 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-30 16:28:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kurt Seifried 2014-10-09 15:25:03 EDT
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 16:28:41 EDT
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 06:18:02 EST
*** Bug 1281383 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.