CVE-2020-15157: containerd v1.2.x can be coerced into leaking credentials during image pull

                							

                <!--X-Body-Begin-->
<!--X-User-Header-->

oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->

By Date

By Thread

</form>

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
CVE-2020-15157: containerd v1.2.x can be coerced into leaking credentials during image pull

<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->

From: "Karp, Samuel" &lt;skarp () amazon com&gt;

Date: Thu, 15 Oct 2020 17:33:53 +0000

<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->

<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
Impact

If a container image manifest in the OCI Image format or Docker Image
V2 Schema 2 format includes a URL for the location of a specific image
layer (otherwise known as a “foreign layer”), the default containerd
resolver will follow that URL to attempt to download it. In v1.2.x but
not 1.3.0 or later, the default containerd resolver will provide its
authentication credentials if the server where the URL is located
presents an HTTP 401 status code along with registry-specific HTTP
headers.

If an attacker publishes a public image with a manifest that directs
one of the layers to be fetched from a web server they control and they
trick a user or system into pulling the image, they can obtain the
credentials used for pulling that image. In some cases, this may be the
user's username and password for the registry. In other cases, this may
be the credentials attached to the cloud virtual instance which can
grant access to other cloud resources in the account.

The default containerd resolver is used by the cri-containerd plugin
(which can be used by Kubernetes), the ctr development tool, and other
client programs that have explicitly linked against it.

Patches

This vulnerability has been fixed in containerd 1.2.14 [1]. containerd
1.3 and later are not affected.

Workarounds

If you are using containerd 1.3 or later, you are not affected. If you
are using cri-containerd in the 1.2 series or prior, you should ensure
you only pull images from trusted sources. Other container runtimes
built on top of containerd but not using the default resolver (such as
Docker) are not affected.

Credits

The containerd maintainers would like to thank Brad Geesaman, Josh
Larsen, Ian Coldwater, Duffie Cooley, and Rory McCune for responsibly
disclosing this issue in accordance with the containerd security policy
[2].

For further details, see 
https://github.com/containerd/containerd/security/advisories/GHSA-742w-89gc-8m9c

[1] https://github.com/containerd/containerd/releases/tag/v1.2.14
[2] https://github.com/containerd/project/blob/master/SECURITY.md

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->

<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->

By Date

By Thread

Current thread:

CVE-2020-15157: containerd v1.2.x can be coerced into leaking credentials during image pull Karp, Samuel (Oct 15)

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->