cgwalters/container-cve-2021-22555Containerisierter Reproducer für die Linux-Privilegieneskalation CVE-2021-22555, mit seccomp-Mitigationsprofilen und Bereitstellungsanleitungen für Kubernetes- und OpenShift-Cluster.
Zunächst wird hier der Exploit-Code von hier als praktischer vorgebauter Container eingebunden: https://github.com/google/security-research/tree/master/pocs/linux/cve-2021-22555
Vorgebauter Container: quay.io/cgwalters/cve-2021-22555
Eine wirksame Gegenmaßnahme besteht darin, seccomp zu aktivieren, das clone(CLONE_NEWUSER) verweigert. Die offizielle Kubernetes-Dokumentation
enthält einige Informationen dazu – überlässt es jedoch dem Benutzer, die Richtlinie auf dem Knoten bereitzustellen. In OpenShift 4 haben wir den machine-config-operator,
der dies übernehmen kann.
Seccomp wird in den offiziellen Dokumenten nicht wirklich behandelt. Der Sicherheitsleitfaden erwähnt jedoch zumindest einiges davon, ebenso wie dieser Blog.
cri-o wird in 4.7 mit einer Standard-seccomp-Richtlinie ausgeliefert, diese ist jedoch standardmäßig nicht aktiviert.
podman und docker werden ebenfalls mit einer Richtlinie ausgeliefert, und diese ist standardmäßig aktiviert (sie unterscheiden sich jedoch, siehe unten).
Die cri-o-Richtlinie verweigert clone(CLONE_NEWUSER) nicht standardmäßig – das gilt auch für die podman-Richtlinie. Die Docker-Standardrichtlinie verweigert clone(CLONE_NEWUSER) jedoch doch:
[root@cosa-devsh ~]# rpm -q podman moby-engine
podman-3.1.2-1.fc33.x86_64
moby-engine-19.03.13-1.ce.git4484c46.fc33.x86_64
[root@cosa-devsh ~]# podman run --rm -ti registry.fedoraproject.org/fedora:34 /bin/sh -c 'unshare -U --keep-caps true'
[root@cosa-devsh ~]# echo $?
0
[root@cosa-devsh ~]# docker run --rm -ti registry.fedoraproject.org/fedora:34 /bin/sh -c 'unshare -U --keep-caps true'
unshare: unshare failed: Operation not permitted
errchan: json: cannot unmarshal array into Go struct field systemdEventMessage.MESSAGE of type string
[root@cosa-devsh ~]# echo $?
1
[root@cosa-devsh ~]#
Oder mit anderen Worten: Docker ist standardmäßig nicht gegen dies anfällig, aber podman und cri-o sind es. (TODO: containerd prüfen)
Der Blogeintrag openshift/seccomp-for-fun-and-profit
behandelt einen Teil davon und verlinkt ein Profil, das der Autor erstellt hat. Diese Richtlinie verweigert clone(CLONE_NEWUSER).
Der Einfachheit halber enthält dieses Repository eine Kopie dieses Profils in more-restricted.json sowie eine Butane-Datei, die ein MachineConfig-Objekt erzeugt, das dieses Profil auf Workern bereitstellt.
Verwende die Beispiel-Pod-Datei, die Folgendes enthält:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: more-restricted.json
Wir erhalten:
$ oc logs pod/cve-2021-22555
[+] Linux Privilege Escalation by theflow@ - 2021
[+] STAGE 0: Initialization
[*] Setting up namespace sandbox...
[-] unshare(CLONE_NEWUSER): Operation not permitted
Das sollte den Exploit unerreichbar machen.
Allerdings müssen Pods dem zustimmen. Weiterhin offen: Untersuchen, ob eine seccomp-Richtlinie über eine SecurityContextConstraint verpflichtend gemacht werden kann, oder ob wir einen mutierenden Admission-Webhook benötigen.