Bug 1730161 (CVE-2019-10200)

Summary: CVE-2019-10200 openshift: Users with permission to schedule pods on master nodes can access credentials for AWS IAM roles
Product: [Other] Security Response Reporter: Sam Fowler <sfowler>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: ahardin, aos-bugs, bleanhar, bmontgom, ccoleman, cscribne, dahernan, dedgar, dominik.mierzejewski, eparis, jburrell, jgoulding, jokerman, mchappel, mfojtik, nstielau, sfowler, sponnaga, sttts
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
A flaw was discovered in OpenShift Container Platform 4 where, by default, users with access to create pods also have the ability to schedule workloads on master nodes. Pods with permission to access the host network, running on master nodes, can retrieve security credentials for the master AWS IAM role, allowing management access to AWS resources. With access to the security credentials, the user then has access to the entire infrastructure. Impact to data and system availability is high.
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-10-25 09:52:58 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: 1729242, 1730165, 1782646, 1782647    
Bug Blocks: 1729923, 1940792    

Description Sam Fowler 2019-07-16 02:59:38 UTC
In the default configuration, OpenShift Container Platform 4 allows users with access to create pods the ability to schedule workloads on master nodes. Pods with permission to access the host network, running on master nodes, can retrieve security credentials for the master AWS IAM role, allowing management access to AWS resources. Pod access to the host network can be granted with the hostnetwork SCC.


Original Bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1729242


Upstream Fix:

https://github.com/openshift/cluster-kube-apiserver-operator/pull/524

Comment 4 Sam Fowler 2019-12-12 03:47:45 UTC
OpenShift Documentation has been updated to include the following:

"If additional workloads are run on master hosts, use caution when providing access to hostnetwork. A workload that runs hostnetwork on a master host is effectively root on the cluster and must be trusted accordingly."

https://docs.openshift.com/container-platform/4.1/authentication/managing-security-context-constraints.html

Comment 5 Sam Fowler 2019-12-12 04:54:46 UTC
Transitioning to Version 2 of the Instance Metadata Service would address this issue:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html

Comment 6 Sam Fowler 2020-05-06 05:59:33 UTC
In reply to comment #5:
> Transitioning to Version 2 of the Instance Metadata Service would address
> this issue:
> 
> https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-
> metadata-service.html

While IMDSv2 seems a valuable defense-in-depth measure (to protect against SSRF etc), it seems a pod with access to the host network on a master node will still be able to retrieve IAM role credentials (via an additional PUT request beforehand).

Comment 9 Sam Fowler 2020-05-20 02:13:15 UTC
Downgrading impact to Moderate as only admin users should be able to schedule pods onto master nodes.

Comment 13 Sam Fowler 2020-08-20 02:18:01 UTC
Mitigation:

Do not run untrusted workloads with `hostnetwork` access on master nodes.

If additional workloads are run on master hosts, use caution when providing access to hostnetwork. A workload that runs hostnetwork on a master host is effectively root on the cluster and must be trusted accordingly.


https://docs.openshift.com/container-platform/4.4/authentication/managing-security-context-constraints.html