Podman does not properly resolve symlinks within containers, allowing for access to files on the host system when executing `podman cp`. Symlinked files inside containers are resolved on the host, not within the container. Upstream Issue: https://github.com/containers/libpod/issues/3211 Upstream Fix: https://github.com/containers/libpod/pull/3214
Created podman tracking bugs for this issue: Affects: fedora-all [bug 1715668]
Function copyBetweenHostAndContainer() in cmd/podman/cp.go does not properly restricts the destination path of the copy operation, allowing an attacker who has control of a container to copy/overwrite files in the host filesystem instead of the container's one.
During the `podman cp` operation, the destination path in the container is just joined with the base directory that contains the / root filesystem of the container from the host point of view. Thus a symlink in one of the components of the destination path can easily go outside the base directory of the container and access the host filesystem.
Set Attack Complexity to High (AC:H) because the attacker cannot really choose what to write in the host filesystem, because that is chosen by the admin when doing the `podman cp` operation. However the attacker can choose where to write in the host filesystem, which may corrupt the host at best or allow the attacker access to it in the worst case. Set User Interaction Required (UI:R) because an admin needs to issue a `podman cp` command to trigger the flaw and Privileges Required Low (PR:L) because the attacker already needs to have some privilege in a running container to setup the attack. For these reasons, the flaw has a Medium Impact.
On RHEL 7.6 and lower versions, users are forced to run podman as root because non-root users cannot run it, so an attacker can potentially overwrite any file writable by root.
Upstream Patch: https://github.com/containers/storage/commit/a6d51f68042c7dfd5a50e56fe291fcb2c6df97fb
Statement: This issue does not affect the versions of podman as shipped with OpenShift Container Platform 4.1 or Red Hat Enterprise Linux 8 as they do not include support for the `cp` command.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Extras Via RHSA-2019:1907 https://access.redhat.com/errata/RHSA-2019:1907
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-10152