Improper input validation in umoci
Date: 2022-02
Affected: go/github.com/opencontainers/umoci
Attack vector: other
Category: vulnerability-disclosure
Severity: Medium
CVE: CVE-2021-29136
CWE: CWE-20
CVSS: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N)

### Impact umoci 0.4.6 and earlier can be tricked into modifying host files by creating a malicious layer that has a symlink with the name "." (or "/"). Because umoci deletes inodes if they change types, this results in the rootfs directory being replaced with an attacker-controlled symlink. Subsequent image layers will then be applied on top of the target of the symlink (which could be any directory on the host filesystem the user running umoci has access to). While umoci does have defences against symlink-based attacks, they are all implemented by resolving things relative to the rootfs directory -- if the rootfs itself is a symlink, umoci resolves it first. This vulnerability affects both "umoci unpack" and "umoci raw unpack". ### Patches This issue has been patched in umoci 0.4.7, see the references section for the specific commit which fixed this vulnerability. ### Workarounds Note that if you use umoci as an unprivileged user (using the --rootless flag) then umoci will not be able to overwrite any files that your user doesn't have access to. Other possible mitigations are to run umoci under an LSM profile such as AppArmor or SELinux to restrict the level of access it has outside of container image directories. ### References * [oss-security public disclosure](https://www.openwall.com/lists/oss-security/2021/04/06/2) * [patch](https://github.com/opencontainers/umoci/commit/d9efc31daf2206f7d3fdb839863cf7a576a2eb57) ### Credits Thanks to Robin Peraglie from Cure53 f


Mitigations:

Architectural layers (MAESTRO):