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 [NEEDINFO]
Summary: CVE-2020-1726 podman: incorrectly allows existing files in volumes to be over...
Keywords:
Status: POST
Alias: CVE-2020-1726
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact:
URL:
Whiteboard:
Depends On: 1801479 1801480 1801571 1801572 1801825
Blocks: 1790619
TreeView+ depends on / blocked
 
Reported: 2020-02-10 11:26 UTC by Riccardo Schirone
Modified: 2020-02-18 10:12 UTC (History)
23 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:
Environment:
Last Closed:
tsweeney: needinfo? (jnovy)


Attachments (Terms of Use)

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:
https://github.com/containers/libpod/commit/997c4b56ed2121726e966afe9a102ed16ba78f93

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
Acknowledgments:

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
Mitigation:

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
Statement:

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.


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