Bug 1858981 (CVE-2020-14336)

Summary: CVE-2020-14336 openshift: restricted SCC allows pods to craft custom network packets
Product: [Other] Security Response Reporter: Jason Shepherd <jshepherd>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: amurdaca, bmontgom, danw, eparis, jburrell, jokerman, nstielau, sponnaga, ykashtan
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in the Restricted Security Context Constraints (SCC), where it allows pods to craft custom network packets. This flaw allows an attacker to cause a denial of service attack on an OpenShift Container Platform cluster if they can deploy pods. The highest threat from this vulnerability is to system availability.
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-26 20:21:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1856529, 1858999, 1874671    
Bug Blocks: 1850665    

Description Jason Shepherd 2020-07-21 00:15:06 UTC
The Restricted Security Context Constraints (SCC) allows pods to craft custom network packets. An attacker can use this flaw to cause a denial of service attack on an OpenShift Container Platform cluster if they have the ability to deploy pods.

Comment 1 Jason Shepherd 2020-07-21 00:15:10 UTC

Name: Yuval Kashtan (Red Hat)

Comment 7 Sam Fowler 2020-07-21 03:01:42 UTC
While removing CAP_NET_RAW from the default capability set is a great change, I think it is better tracked as security hardening issue rather than a CVE. It's a stretch IMO to consider the inclusion of this capability a flaw on it's own, considering that other projects also include it by default, e.g.

Docker: https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities
libcontainer: https://github.com/opencontainers/runc/blob/master/libcontainer/SPEC.md#security

I think we want to avoid setting a precedent of CVE assignment everytime a project changes its capability set.

Comment 13 Jason Shepherd 2020-07-28 22:04:55 UTC
In OpenShift Container Platform 3.11 if you are using an alternative CNI [1] you are at greater risk of exploitation.

[1] https://docs.openshift.com/container-platform/3.11/architecture/networking/network_plugins.html

Comment 18 errata-xmlrpc 2020-10-26 14:42:07 UTC
This issue has been addressed in the following products:

  Red Hat OpenShift Container Platform 4.5

Via RHSA-2020:4320 https://access.redhat.com/errata/RHSA-2020:4320

Comment 19 Product Security DevOps Team 2020-10-26 20:21:16 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):


Comment 20 errata-xmlrpc 2020-10-27 16:24:45 UTC
This issue has been addressed in the following products:

  Red Hat OpenShift Container Platform 4.6

Via RHSA-2020:4298 https://access.redhat.com/errata/RHSA-2020:4298

Comment 21 Jason Shepherd 2020-12-01 06:36:09 UTC

On OCP 3.11 create a custom SCC based on 'restricted' and also drop the NET_RAW capability[1]. Assign this custom SCC to any users, or groups which create pods you want to protect. See the documentation for more information [2]. 
[1] https://access.redhat.com/solutions/5611521
[2] https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html

Comment 22 Jason Shepherd 2021-01-11 01:45:37 UTC

By default, the OpenShift Container Platform uses the OpenShift SDN network interface. This interface makes this attack impractical by implementing IPTable rules on the host side of the virtual network interface, isolating network traffic to within the pod.

If the OpenShift Container Platform has the sriov-network-operator deployed, it is at a greater risk for exploitation. 

If installing a new OCP 4.6 cluster no changes are required. If upgrading a cluster from an earlier version to 4.5.16 be sure to delete 99-worker-generated-crio-capabilities and 99-master-generated-crio-capabilities machine controllers once you have tested that dropping NET_RAW does not break your cluster workload.