Bug 1151208 (CVE-2014-8164) - CVE-2014-8164 CFME: http.verify_mode = OpenSSL::SSL::VERIFY_NONE
Summary: CVE-2014-8164 CFME: http.verify_mode = OpenSSL::SSL::VERIFY_NONE
Keywords:
Status: CLOSED DEFERRED
Alias: CVE-2014-8164
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
: 1281383 (view as bug list)
Depends On: 1151209 1151210
Blocks: 1129011
TreeView+ depends on / blocked
 
Reported: 2014-10-09 19:25 UTC by Kurt Seifried
Modified: 2020-12-09 09:06 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-30 20:28:41 UTC


Attachments (Terms of Use)

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. ***


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