39 lines
1.6 KiB
Markdown
39 lines
1.6 KiB
Markdown
# CVE-2022-27650: crun/Moby started containers with a non-empty inheritable capability set
|
|
|
|
**Scope:** [audit](../README.md) · [README](../../README.md) · [COMPARISON](../../COMPARISON.md) · [docs/RESEARCH](../../docs/RESEARCH.md)
|
|
|
|
CVSS 7.5. Fixed in crun 1.4.4; related Moby advisory GHSA-wr4f-w546-m398.
|
|
|
|
## Source
|
|
|
|
- [Alpine security tracker](https://security.alpinelinux.org/vuln/CVE-2022-27650)
|
|
- [Debian security tracker](https://security-tracker.debian.org/CVE-2022-27650)
|
|
|
|
## Relevance to doos
|
|
|
|
crun (and, separately, Moby) could start a container process with inheritable
|
|
capabilities still set in its capability set, rather than cleared. A program inside the
|
|
container carrying file capabilities (`cap_setuid+ep` and similar) can raise an
|
|
inheritable capability into its permitted set across `execve`, turning a leftover
|
|
inheritable bit into a real privilege gain. doos drops to a fixed capability bounding
|
|
set in `Hardening::apply()` before exec; the inheritable set specifically is the thing
|
|
this bug class is about, and it is worth confirming directly rather than only checking
|
|
the effective set (which is what the README and `docs/RESEARCH.md` already measure via
|
|
`CapEff`).
|
|
|
|
|
|
## What the check does
|
|
|
|
Attaches a container with default hardening and reads `/proc/self/status`'s `CapInh`
|
|
line. Anything other than all-zero is FAIL.
|
|
|
|
|
|
## Caveats
|
|
|
|
Only checks default hardening; `--hardening relaxed` is documented as removing capability
|
|
restrictions entirely and is out of scope here, same as the other hardening-dependent
|
|
checks in this audit.
|
|
|
|
|
|
Run: `make test` in this directory, or `make -C audit test` from the repo root.
|