Bug 1810383 (CVE-2020-1764)
| Summary: | CVE-2020-1764 kiali: JWT cookie uses default signing key | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Mark Cooper <mcooper> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | unspecified | CC: | gmollett, kconner, mazz, rcernich, security-response-team |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | kiali 1.15.1 | Doc Type: | If docs needed, set a value |
| Doc Text: |
A hard-coded cryptographic key vulnerability in the default configuration file was found in Kiali. A remote attacker could abuse this flaw by creating their own JWT signed tokens and bypass Kiali authentication mechanisms, possibly gaining privileges to view and alter the Istio configuration.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-03-26 04:31:50 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1810199 | ||
|
Description
Mark Cooper
2020-03-05 06:25:28 UTC
Mitigation:
The Kiali configuration can be manually updated for ServiceMesh so that the default signing_key cannot be easily determined:
oc get kiali -n $(oc get kiali --all-namespaces --no-headers -o custom-columns=NS:.metadata.namespace) -o yaml | sed "s/spec:/spec:\n login_token:\n signing_key: $(chars=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890; for i in {1..20}; do echo -n "${chars:RANDOM%${#chars}:1}"; done; echo)/" | oc apply -f -
Acknowledgments: Name: Dagan Henderson (Akoya, LLC) This issue has been addressed in the following products: Openshift Service Mesh 1.0 Via RHSA-2020:0975 https://access.redhat.com/errata/RHSA-2020:0975 This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-1764 External References: https://kiali.io/news/security-bulletins/kiali-security-001/ Statement:
If exploited, an attacker can perform all Kiali admin functions via the API including:
- View the logs of a pod
- View Istio metrics, tracing etc.
- Alter Istio routing configurations:
- Change the pod availability: adding variances to the weighting, i.e. all traffic goes to 1 pod, or 95% of all traffic.
- Prevent traffic reaching a pod, DoS
Whilst OpenShift ServiceMesh Kiali uses the default signing key for JWT cookies, it also includes an access_token. This token is generated with a successful login and cannot be easily determined.
To access the Kiali API in this case, a valid session token would need to be captured first and then added to the JWT cookie.
|