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.This issue was introduced in version 1.6.0.
The product makes files or directories accessible to unauthorized actors, even though they should not be.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Libpod | Libpod_project | 1.6.0 (including) | 1.6.0 (including) |
| Red Hat Enterprise Linux 8 | RedHat | container-tools:rhel8-8020020200324071414.0d58ad57 | * |
| Red Hat OpenShift Container Platform 4.3 | RedHat | podman-0:1.6.4-7.el8 | * |
| Podman | Ubuntu | trusty | * |
Web servers, FTP servers, and similar servers may store a set of files underneath a “root” directory that is accessible to the server’s users. Applications may store sensitive files underneath this root without also using access control to limit which users may request those files, if any. Alternately, an application might package multiple files or directories into an archive file (e.g., ZIP or tar), but the application might not exclude sensitive files that are underneath those directories. In cloud technologies and containers, this weakness might present itself in the form of misconfigured storage accounts that can be read or written by a public or anonymous user.