A flaw was found in Openshift OAuth server. An XSS vulnerability in oauth/token/request endpoint that could allow to retrieve a token for CLI usage when using non default configs.
Acknowledgments: Name: Mo Khan (Red Hat)
Statement: This issue affects the OAuth server shipped in OpenShift Container Platform version v3.0 through v3.11. Red Hat Product Security has rated this issue as having a security impact of Moderate. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.
Mitigation: Since at least v3.4, the OpenShift documentation [1] has specified the format for corsAllowedOrigins to accurately match intended hostnames. Since at least v3.7, installs will default to use the correct regular expression formatted variables. Earlier versions may be configured with plain strings, a configuration which will persist across cluster upgrades, opening them to cross origin vulnerabilities such as this. At a minimum, you should ensure that the corsAllowedOrigin definition within master-config.yaml contains elements in the form ~~~ corsAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) ~~~ and not the form ~~~ corsAllowedOrigins: - domain.com ~~~ as the first will permit cross origin requests only if the host matches exactly, whereas the second will permit from any host that merely contains the string (such as ABCDdomain.com or even domain.comABCD.com). Footnotes: [1] https://docs.openshift.com/container-platform/3.4/architecture/infrastructure_components/web_console.html#corsAllowedOrigins
Tracking this to the atomic-openshift component. 3.6 cluster-master: # rpm -qf /usr/bin/openshift 3.11 cluster-master: # ps -ef | grep openshift # cat /proc/(PID)/cgroup ... determine docker container ID from cgroup identifier # docker exec -ti (container) /bin/bash $ rpm -qf /usr/bin/openshift
Additional notes: This is limited to OpenShift ... the affected endpoint does not exist in Kubernetes. The OpenShift OAuth server exposes a custom endpoint at <master>/oauth/token/request that can be used to get a token for CLI usage. Without additional CSRF protections, tokens may be able to be generated without user interaction (e.g. when the user has a valid session open with the identity provider). Due to the token being potentially generated we are left overly dependent on CORS to now prevent it from being extracted from the user's browser.
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 3.11 Via RHSA-2019:1851 https://access.redhat.com/errata/RHSA-2019:1851
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-2019-3876