2

I saw the recent CVE-2022-0492 that can enable container escape, and I have a decent understanding of cgroups and container capabilities, but not very familiar with how hybrid cgroup v1/v2 works, nor how cgroups and capabilities work together. However, looking at the commit the vulnerable code is only related to cgroups v1.

So my question is if this is only exploitable when using cgroups v1 for containers, or if the host is also vulnerable while it's using cgroups v1, but then uses cgroups v2 for container namespaces in hybrid mode? Does using cgroups v2 for both hosts and containers reduce attack surface?

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
4oo4
  • 25
  • 4

1 Answers1

1

However, looking at the commit the vulnerable code is only related to cgroups v1.

Yes.

not very familiar with how hybrid cgroup v1/v2 works, nor how cgroups and capabilities work together.

Check https://github.com/systemd/systemd/blob/main/docs/CGROUP_DELEGATION.md

if this is only exploitable when using cgroups v1 for containers, or if the host is also vulnerable while it's using cgroups v1, but then uses cgroups v2 for container namespaces in hybrid mode?

Here, I use Ubuntu 20.04.2 LTS as host. systemd --version show that this OS running in hybrid mode. You could check it by mount | grep -i cgroup , you will see fstype cgroup and cgroup2 existing at the same time. However, under the default circumstance, docker system info will tell you, they run containers under cgroup v1. The containers running in cgroup v2 is not vulnerable.

Does using cgroups v2 for both hosts and containers reduce attack surface?

I think so.

PotatoChips
  • 26
  • 1
  • Following https://rootlesscontaine.rs/getting-started/common/cgroup2/, it seems better to check if the file `/sys/fs/cgroup/cgroup.controllers` exists on host, to confirm if cgroup2 is effectively used. – cactuschibre Aug 31 '22 at 08:04