The decompression functionality of github.com/containers/storage in all versions starting from v1.23.8, is susceptible to a Denial of Service (DoS) when used during container image pulls by tools like podman and cri-o.
Acknowledgments: Name: Aviv Sasson (Palo Alto Networks)
Upstream fix: https://github.com/containers/storage/commit/306fcabc964470e4b3b87a43a8f6b7d698209ee1
Created podman tracking bugs for this issue: Affects: fedora-all [bug 1945639]
Most versions of podman/buildah/skopeo in Red Hat Enterprise Linux 8 are not affected by this flaw because the version of containers/storage embedded there is old enough to not have the `defer uncompressed.Close()` necessary to trigger this issue.
The issue was first added/exposed here [1] and when the defer function close is called regardless if the function is in error or not. For example if an image layer is compressed with something unexpected it creates an unexpected error condition. However since the deferring close function is waiting for the uncompressed stream which will never occur, this creates the DoS. Given it really is only exposed since [1], this means it only affects v1.23.8 of containers/storage and greater. For applications like podman the affect is minimal - podman pull and it seemingly waits to download the image forever, cancel and the affect is negated. For something like crio the affect is more severe, with the malicious image locking the service up, BUT it is still somewhat responsive. The service then must be killed before returning back to normal. We've also confirmed when used on OCP, that the node `doesn't` become unresponsive and thus the work load `does not` then gets shifted to another node. [1] https://github.com/containers/storage/blob/master/layers.go#L1416
Created buildah tracking bugs for this issue: Affects: fedora-all [bug 1947288] Created skopeo tracking bugs for this issue: Affects: fedora-all [bug 1947289]
Hi Mark, we'll need podman and cri-o bugs as well for this. BTW, cri-o is a fedora module and not regular package.
Peter Hunt, the cri-o maintainer said cri-o on fedora should be good to go already. So, we may not need that after all.
I heard from podman upstream that podman v3.1.0 also contains the fix already, so we're good to go on the podman side as well.
External References: https://unit42.paloaltonetworks.com/cve-2021-20291/
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.7 Via RHSA-2021:1150 https://access.redhat.com/errata/RHSA-2021:1150
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-2021-20291
Statement: The vulnerability was first exposed in v1.23.8 of containers/storage (and subsequently fixed in v1.28.1) with this git commit [1]. * In OpenShift Container Platform (OCP) only 4.7 contains a version of CRI-O (and openshift/ose-docker-builder) which uses a vulnerable version of containers/storage. Subsequently this has been addressed in OCP 4.7.7. * Red Hat Quay quay-builder-container is not affected because it uses a version of github.com/containers/storage earlier than v1.23.8 * Red Hat Openshift Virtualization is not affected because all containers depending on github.com/containers/storage use a version earlier than v1.23.8 [1] - https://github.com/containers/storage/blob/e9989a949a0d2c32fa82d3ff1076e33cfec58cb9/layers.go#L1332
FEDORA-2021-a3703b9dc8 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-c56a213327 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
With Migration Toolkit for Contains, the openshift-migration-plugin-container only packages an older version of containers/storage v1.15.3 and hence it is not affected. Upstream reference: https://github.com/konveyor/openshift-migration-plugin/blob/cbc29cae77bd1046165166d9f5c2c55488d24e2f/Gopkg.lock#L209
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.8 Via RHSA-2021:2438 https://access.redhat.com/errata/RHSA-2021:2438
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:4154 https://access.redhat.com/errata/RHSA-2021:4154
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHBA-2022:0348 https://access.redhat.com/errata/RHBA-2022:0348
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2022:7954 https://access.redhat.com/errata/RHSA-2022:7954
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2022:7955 https://access.redhat.com/errata/RHSA-2022:7955
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2022:8008 https://access.redhat.com/errata/RHSA-2022:8008