Bug 1444033 - User is allowed to add a Containers Provider using a bad Custom Certificate
Summary: User is allowed to add a Containers Provider using a bad Custom Certificate
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: UI - OPS
Version: 5.8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: GA
: 5.8.2
Assignee: Beni Paskin-Cherniavsky
QA Contact: Pavel Zagalsky
URL:
Whiteboard: container
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-20 13:07 UTC by Pavel Zagalsky
Modified: 2017-12-05 15:50 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-20 08:50:50 UTC
Category: ---
Cloudforms Team: Container Management
Target Upstream Version:


Attachments (Terms of Use)
BadCertificate (1.04 KB, text/x-vhdl)
2017-04-20 13:07 UTC, Pavel Zagalsky
no flags Details
Wrong Cert log (62.96 KB, text/plain)
2017-04-20 13:08 UTC, Pavel Zagalsky
no flags Details

Description Pavel Zagalsky 2017-04-20 13:07:42 UTC
Created attachment 1272956 [details]
BadCertificate

Description of problem:
When selecting SSL trusting custom CA as a Security Protocol option and feeding it an incorrect certificate the validation passes successfully

Version-Release number of selected component (if applicable):
5.8.0.10

How reproducible:
Always

Steps to Reproduce:
1. Go to Compute --> Containers --> Providers
2. Select Configuration --> Add Existing Provider
3. Add provider's name/hostname/port/token and select SSL trusting custom CA as the option for Sec Protocol
4. In Trusted CA Certificates text area add a correctly formatted but incorrect custom certificate (example attached)
5. Try to validate and add the provider

Actual results:
The validation works and the provider is added successfully

Expected results:
The validation should fail

Additional info:
Attached a correctly formatted yet incorrect custom certificate.
Logs

Comment 2 Pavel Zagalsky 2017-04-20 13:08:19 UTC
Created attachment 1272957 [details]
Wrong Cert log

Comment 3 Federico Simoncelli 2017-04-21 10:25:44 UTC
Unable to reproduce: I added an OCP provider using the BadCertificate.crt in attachment and the error is: "Credential validation was not successful: HTTP status code , SSL_connect returned=1 errno=0 state=error: certificate verify failed"

Assigning to Beni for further investigation.

Comment 4 Mooli Tayer 2017-04-23 13:11:20 UTC
Assigning to beni per comment 3.

Beni I believe this is a duplicate of another bug you mentioned?

Comment 5 Beni Paskin-Cherniavsky 2017-04-24 17:26:46 UTC
Not duplicate.
I can reproduce.  You can't try attached cert on any provider (that's caught correctly), need to take correct cert and modify its end a little.

Example of cert mutation (including `openssl x509 -text` diff) on my provider vm-48-131.eng.lab.tlv.redhat.com:
https://gist.github.com/cben/bdbe1fac36192da827398fedc70523c1
I'm getting »Credential validation was successful«

I'm not sure it's a security bug.
The cert I tell CFME to trust differs from CA's real root in its self-signature.  Nobody really cares (?) how a self-singing cert signs itself, only that the openshift cert is still signed by it, which it is.

- `oc login --oc login --certificate-authority=ca.crt.bad` connects happily with such cert (and I can use commands like `oc status`, no complaints)!

- Curl refuses:
  curl: (35) You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert.

Kurt - can you help us figure out if I got this right, and if Ruby trusting such modified CA cert is a problem?

Comment 6 Kurt Seifried 2017-04-24 19:19:24 UTC
See email thread, but in short:

this appears to be hardening, but we want to make sure there isn't some way to abuse this.

Comment 7 Kurt Seifried 2017-04-24 19:28:29 UTC
oh also this may also be a flaw/issue/hardening upstream in Ruby on Rails, once we know a bit more I'll rope them in if needed.

Comment 8 Beni Paskin-Cherniavsky 2017-04-25 13:27:50 UTC
Not in Rails, perhaps ruby's OpenSSL lib (seems to ship with ruby as well as separate gem, not sure of the relation)

Comment 10 Beni Paskin-Cherniavsky 2017-06-19 10:30:35 UTC
I'd like to close as NOTABUG for CFME.
To repeat, the CFME scenario is:

- A private CA with self-signed root cert R
  issued a cert P for say myopenshift.example.com.

- A user adds myopenshift.example.com as a CFME provider, telling CFME to trust
  certs signed by R', where R' is R with a typo.
  The typo is in the self-signing part of R (R'.signature != R.signature);
  crucially the chain is still valid:
  - P.issuer == R'.subject == R.subject
  - P.signature can be verified by R'.public_key == R.public_key

- CFME trusts myopenshift.example.com that presents P.

Kurt, is there a better place to track this (*if* there is anything to track)?

My conclusions reading RFC 3280: https://security.stackexchange.com/a/162244

Comment 11 Kurt Seifried 2017-06-19 23:20:13 UTC
I'm going to bring this up with ruby on rails, sorry for going awol (stackguard is done! yippeee!). Can I share all the details with upstream?

Comment 12 Federico Simoncelli 2017-06-20 08:50:50 UTC
(In reply to Kurt Seifried from comment #11)
> Can I share all the details with upstream?

Sure.

Closing this for now.


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