===================================================================                           CERT-Renater

                 Note d'Information No. 2021/VULN123
_____________________________________________________________________

DATE                : 22/03/2022

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running CRI-O versions prior to 1.19.6,
                          1.20.7, 1.21.6, 1.22.3, 1.23.2, 1.24.0.

===================================================================== 
https://github.com/cri-o/cri-o/security/advisories/GHSA-6x2m-w449-qwx7
https://github.com/cri-o/cri-o/security/advisories/GHSA-w2j5-3rcx-vx7x
_____________________________________________________________________

cri-o: Arbitrary code execution in cri-o via abusing 
“kernel.core_pattern” kernel parameter

Critical	
haircommander published GHSA-6x2m-w449-qwx7

Package
CRI-O ()

Affected versions
>1.19.0

Patched versions
1.19.6, 1.20.7, 1.21.6, 1.22.3, 1.23.2, 1.24.0


Description

Impact
A flaw introduced in CRI-O version 1.19 which an attacker can use to 
bypass the safeguards and set arbitrary kernel parameters on the host. 
As a result, anyone with rights to deploy a pod on a Kubernetes cluster 
that uses the CRI-O runtime can abuse the “kernel.core_pattern” kernel 
parameter to achieve container escape and arbitrary code execution as 
root on any node in the cluster.


Patches
The patches will be present in 1.19.6, 1.20.7, 1.21.6, 1.22.3, 1.23.2, 
1.24.0


Workarounds
Users can set manage_ns_lifecycle to false, which causes the sysctls to 
be configured by the OCI runtime, which typically filter these cases. 
This option is available in 1.20 and 1.19. Newer versions don't have 
this option.

An admission webhook could be created to deny pods that specify a + in 
the sysctl value of a pod.
A PodSecurityPolicy [deprecated] could be created, specifying all 
sysctls as forbidden like so:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
   name: sysctl-psp
spec:
   forbiddenSysctls:
     - "*"
However, this option will not work if any sysctls are required by any 
pods in the cluster.


Credits
Credit for finding this vulnerability goes to John Walker and Manoj 
Ahuje of Crowdstrike. The CRI-O community deeply thanks them for the report.


For more information
If you have any questions or comments about this advisory:


Open an issue in the CRI-O repo
To make a report, email your vulnerability to the private
cncf-crio-security@lists.cncf.io list
with the security details and the details expected for all CRI-O bug
reports.


CVE ID
CVE-2022-0811

GHSA ID
GHSA-6x2m-w449-qwx7

_____________________________________________________________________

Sysctls applied to containers with host IPC or host network namespaces 
can affect the host

Moderate	haircommander published GHSA-w2j5-3rcx-vx7x
Package
CRI-O ()

Affected versions
CRI-O

Patched versions
1.23.1, 1.22.2, 1.21.5, 1.20.6, 1.19.5


Description

Impact
Before setting the sysctls for a pod, the pods namespaces must be 
unshared (created). However, in cases where the pod is using a host 
network or IPC namespace, a bug in CRI-O caused the namespace creating 
tool pinns to configure the sysctls of the host. This allows a malicious 
user to set sysctls on the host, assuming they have access to 
hostNetwork and hostIPC.

Any CRI-O cluster after CRI-O 1.18 that drops the infra container
1.22 and 1.23 clusters drop infra container by default, and are thus 
vulnerable by default.


Patches
CRI-O versions 1.24.0, 1.23.1, 1.22.2, 1.21.5, 1.20.6, 1.19.5 all have 
the patches.


Workarounds
Users can set manage_ns_lifecycle to false, which causes the sysctls to 
be configured by the OCI runtime, which typically filter these cases. 
This option is available in 1.20 and 1.19. Newer versions don't have 
this option.

An admission webhook could also be created to deny pods that use host 
IPC or network namespaces and also attempt to configure sysctls related 
to that namespace.


For more information
If you have any questions or comments about this advisory:

Open an issue in the CRI-O repo
To make a report, email your vulnerability to the private
cncf-crio-security@lists.cncf.io list
with the security details and the details expected for all CRI-O bug
reports.

========================================================+ CERT-RENATER        |    tel : 01-53-94-20-44         +
+ 23/25 Rue Daviel    |    fax : 01-53-94-20-41         +
+ 75013 Paris         |   email:cert@support.renater.fr +
=======================================================