memory corruption in net/packet/af_packet.c leads to elevation of privilege
CVE: CVE-2020-14386
Component: kernel
CWE: CWE-786
Severity: Important
CVSS v3: 7.9/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Release date: 2020-09-03T00:00:00+00:00

A flaw was found in the Linux kernel. Memory corruption can be exploited to gain root privileges from unprivileged processes. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

Statement: Only local users with CAP_NET_RAW capability enabled can trigger this issue.

For OpenShift Container Platform 4, pods in the default restricted SCC are granted CAP_NET_RAW by default. An attacker can exploit this if they can run arbitrary container images on the target cluster.

Remediation:
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
If the CAP_NET_RAW capability disabled by default (which is true for Red Hat Enterprise Linux), then only a privileged user can trigger this bug. The mitigation is to disable CAP_NET_RAW capability for regular users and for executables.

On Red Hat Enterprise Linux 8 CAP_NET_RAW capability can be also gained by exploiting unprivileged user namespaces. The mitigation is to disable unprivileged user namespaces by setting user.max_user_namespaces to 0:

# echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf
# sysctl -p /etc/sysctl.d/userns.conf

OpenShift Container Platform 4.5 and 4.4 this can be mitigated by removing `CAP_NET_RAW` from the default cri-o capabilities provided to pods (NOTE: This may prevent `ping` from working in unprivileged pods. This fix has not been validated for OpenShift 4.3 or below):
```
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 50-reset-crio-capabilities
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,W2NyaW8ucnVudGltZV0KZGVmYXVsdF9jYXBhYmlsaXRpZXMgPSBbCiAgICAiQ0hPV04iLAogICAgIkRBQ19PVkVSUklERSIsCiAgICAiRlNFVElEIiwKICAgICJGT1dORVIiLAogICAgIlNFVEdJRCIsCiAgICAiU0VUVUlEIiwKICAgICJTRVRQQ0FQIiwKICAgICJORVRfQklORF9TRVJWSUNFIiwKICAgICJTWVNfQ0hST09UIiwKICAgICJLSUxMIiwKXQo=
        filesystem: root
        mode: 0644
        path: /etc/crio/crio.conf.d/reset-crio-capabilities.conf
```

Create this MachineConfig object via e.g. `oc apply`.  More information about MachineConfig can be found here: 
https://github.com/openshift/machine-config-operator
https://docs.openshift.com/container-platform/4.5/architecture/architecture-rhcos.html

In order to monitor the rollout of this change, use `oc describe machineconfigpool/worker`.

Check for any pods which start to crash after this is applied; they may need to be adjusted request `CAP_NET_RAW` explicitly.  More information:
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container
https://docs.openshift.com/container-platform/4.5/authentication/managing-security-context-constraints.html