Bug 1801152 (CVE-2020-1726) - CVE-2020-1726 podman: incorrectly allows existing files in volumes to be overwritten by a container when it is created
Summary: CVE-2020-1726 podman: incorrectly allows existing files in volumes to be over...
Alias: CVE-2020-1726
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact:
Depends On: 1889777 1801479 1801480 1801571 1801572 1801825
Blocks: 1790619
TreeView+ depends on / blocked
Reported: 2020-02-10 11:26 UTC by Riccardo Schirone
Modified: 2021-02-16 20:38 UTC (History)
25 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
A flaw was discovered in Podman where it incorrectly allows containers when created to overwrite existing files in volumes, even if they are mounted as read-only. When a user runs a malicious container or a container based on a malicious image with an attached volume that is used for the first time, it is possible to trigger the flaw and overwrite files in the volume.
Clone Of:
Last Closed: 2020-03-10 22:31:46 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:0680 0 None None None 2020-03-10 22:07:47 UTC
Red Hat Product Errata RHSA-2020:1650 0 None None None 2020-04-28 15:36:49 UTC

Description Riccardo Schirone 2020-02-10 11:26:15 UTC
podman incorrectly allows containers, when created, to populate volumes that already have existing data inside. A malicious container image may use this flaw to overwrite existing files in a volume, even if it is mounted in read-only mode. The attack is possible only the first time a volume is used.

Comment 1 Riccardo Schirone 2020-02-10 11:30:41 UTC
Vulnerability introduced in upstream commit:

First vulnerable upstream version is v1.6.0, which includes the above commit.

Comment 2 Riccardo Schirone 2020-02-10 11:33:18 UTC
Function mountNamedVolume() is responsible for copying the content of the destination volume directory from the container to the volume. The copy (and the attack) happens only the first time because it is done when vol.state.NeedsCopyUp is True, which it is only at the beginning, since that field is set to False after perfoming the copy.

Comment 3 Riccardo Schirone 2020-02-10 11:36:29 UTC
docker is not affected by this issue, even if it does support populating a volume using a container, as it checks whether the volume is empty before copying data from the container to the volume. Function populateVolumes() in create_unix.go of the docker code base is responsible for copying data from the container's rootfs into the volume. populateVolumes() calls CopyImagePathContent(), which in turn calls copyExistingContents() that checks whether the destination folder (the volume path) is empty or not. If the volume is not empty, the copy is not performed, thus preventing a malicious image from copying data into an existing container.

Comment 16 Riccardo Schirone 2020-02-10 16:01:04 UTC

Name: Tristan De Cacqueray (Red Hat)

Comment 28 Matthew Heon 2020-02-11 15:19:28 UTC
Upstream PR with fix: https://github.com/containers/libpod/pull/5168

Comment 30 Riccardo Schirone 2020-02-11 17:12:26 UTC

If a volume needs to be attached as read-only to an untrusted container or container image, first attach it to a trusted container. Using the volume for the first time will make the attack impossible for other containers that are going to use the volume.

Comment 31 Jason Shepherd 2020-02-12 04:16:45 UTC

Podman versions earlier than 1.6.0 are not affected. That includes the podman versions in OCP 4.2 and earlier.

Comment 34 Tom Sweeney 2020-02-13 18:59:58 UTC
Setting to Post and assigning to Jindrich for kitting needs.

Comment 36 errata-xmlrpc 2020-03-10 22:07:45 UTC
This issue has been addressed in the following products:

  Red Hat OpenShift Container Platform 4.3

Via RHSA-2020:0680 https://access.redhat.com/errata/RHSA-2020:0680

Comment 37 Product Security DevOps Team 2020-03-10 22:31:46 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):


Comment 39 errata-xmlrpc 2020-04-28 15:36:46 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2020:1650 https://access.redhat.com/errata/RHSA-2020:1650

Note You need to log in before you can comment on or make changes to this bug.