| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/containerd/containerd | < 1.7.29 | 1.7.29 |
| github.com/containerd/containerd/v2 | ≥ 2.1.0-beta.0, < 2.1.5≥ 2.2.0-beta.0, < 2.2.0< 2.0.7 | 2.1.52.2.02.0.7 |
| containerd | = 2.2.0≥ 2.0.0, < 2.0.7≥ 2.1.0, < 2.1.5< 1.7.29 | 2.0.72.1.51.7.29 |
An overly broad default permission vulnerability was found in containerd.
/var/lib/containerd was created with the permission bits 0o711, while it should be created with 0o700
/run/containerd/io.containerd.grpc.v1.cri was created with 0o755, while it should be created with 0o700
/run/containerd/io.containerd.sandbox.controller.v1.shim was created with 0o711, while it should be created with 0o700The directory paths may differ depending on the daemon configuration.
When the temp directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700.
This bug has been fixed in the following containerd versions:
Users should update to these versions to resolve the issue. These updates automatically change the permissions of the existing directories.
[!NOTE]
/run/containerdand/run/containerd/io.containerd.runtime.v2.taskare still created with 0o711. This is an expected behavior for supporting userns-remapped containers.
The system administrator on the host can manually chmod the directories to not have group or world accessible permisisons:
chmod 700 /var/lib/containerd
chmod 700 /run/containerd/io.containerd.grpc.v1.cri
chmod 700 /run/containerd/io.containerd.sandbox.controller.v1.shim
An alternative mitigation would be to run containerd in rootless mode.
The containerd project would like to thank David Leadbeater for responsibly disclosing this issue in accordance with the containerd security policy.
If you have any questions or comments about this advisory:
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeTo report a security issue in containerd: