Advisory & Announcement: image and distribution spec releases for CVE-2021-41190

[Vincent Batts]

Hey everyone,

Today we published advisory CVE-2021-41190, with corresponding releases
for distribution-spec and image-spec.

The specifications themselves needed additional clarification so that
implementations of container registries, and the clients that parse data
received from registries can have more securely defined behavior.

The undefined behavior this advisory addresses is a "type confusion"
where a JSON document for a container's manifest could masquerade as
both an image-index or a manifest without modification to the digest,
relying only on the HTTP `Content-type` header provided by the registry.

This behavior would have been mitigated by the presence of the
`mediaType` field in these JSON documents. As such a notable, but
non-breaking change introduced in these releases is un-reserving the
`mediaType` field for use, and actively encouraging it's use.

Severity: MEDIUM (moderate in Github GHSA)

Advisory links:
- https://github.com/opencontainers/distribution-spec/security/advisories/GHSA-mc8v-mgrf-8f4m
- https://github.com/opencontainers/image-spec/security/advisories/GHSA-77vh-xpmg-72qh
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41190

Release links:
- https://github.com/opencontainers/distribution-spec/releases/tag/v1.0.1
- https://github.com/opencontainers/image-spec/releases/tag/v1.0.2

Workarounds:
Software attempting to deserialize an ambiguous document may reject the
document if it contains both “manifests” and “layers” fields or
“manifests” and “config” fields.

Coordination:
This advisory was first reported by jonjohnsonjr, and big thanks to the
coordination of members of secu...@opencontainers.org and a number of
open source projects and container registry services.

Kudos:
Due to the nature of specifications, and validation of this
cross-ecosystem, open source organization, this report was handled
respectfully. Really emphasizing "same team, different company".

vb

[Josh Dolitsky]

Extra extra kudos to Sam Karp for getting everyone organized around this

--
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencontainers.org.

[Karp, Samuel]

Thanks Josh! I want to echo what Vincent said though; this was absolutely a team effort and I'm really glad we could come together to address it quickly and efficiently.

Sam

On Wed, 2021-11-17 at 15:22 -0500, Josh Dolitsky wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

[Sebastiaan van Stijn]

Thanks everyone!

We just published docker 20.10.11 and containerd.io v1.4.12 on download.docker.com with fixes for this advisory.

the containerd project also released containerd 1.5.8, and I saw that BuildKit tagged v0.9.3 with similar fixes.

On 17 Nov 2021, at 22:41, 'Karp, Samuel' via dev <d...@opencontainers.org> wrote:



[Tycho Andersen]

Hi all,

On Wed, Nov 17, 2021 at 02:14:33PM -0500, Vincent Batts wrote:
> Release links:
> - https://github.com/opencontainers/distribution-spec/releases/tag/v1.0.1
> - https://github.com/opencontainers/image-spec/releases/tag/v1.0.2

What's the plan for releasing an image-spec from git main?

Tools like github's dependabot (and others) don't think I've fixed the
CVE when using the image-spec main branch as a dependency, but some
code I have depends on things that are only in the main branch (e.g.
the zstd media types).

While it's "fine" from a security point, it is a bit annoying to have
to ignore the output of these tools.

Thanks,

Tycho

[Vincent Batts]

Good question. We discussed this during the coordination. And now
looking at how I did the release, I think I messed it up.

I am not going to rebase main, messing up history.

The v1.0 branch on next release will likely just get a merge commit from
main, which looks gross on the git history graph, but so it goes.

The big takeaway for me on this is to discuss a next point release.
(`git log --no-merges v1.0...origin/main`)

vb

[Tycho Andersen]

I wonder if merging v1.0.2 into main would fix it? Then you'd have
v1.0.2 in the lineage of main, and I think the tools would be happy.

I agree that rebasing is probably bad at this point.

Thanks,

Tycho

[Vincent Batts]

Maybe? Attached is the ugly bubbles that would make.

vb

[Tycho Andersen]

At least basic git thinks the branch is 1.0.2-based afterwards:

~/packages/image-spec main $ git describe HEAD
v1.0.1-105-g693428a
~/packages/image-spec main $ git merge v1.0.2
Auto-merging specs-go/version.go
Auto-merging manifest.md
Auto-merging image-index.md
Merge made by the 'recursive' strategy.
~/packages/image-spec main $ git describe HEAD
v1.0.2-106-gbf5f4fb

I'd vote for sensible tooling output over ugly git graphs, but that's just me
:)

Tycho

[Vincent Batts]

Solid argument.

Anyone opposed?

vb

[Vincent Batts]

https://github.com/opencontainers/image-spec/pull/878
https://github.com/opencontainers/distribution-spec/pull/309

when opening this I noticed that dependabot had an alert on
distribution-spec itself... so hopefully this will fix that.

vb

[Tycho Andersen]

On Tue, Nov 23, 2021 at 11:55:00PM -0500, Vincent Batts wrote:
> https://github.com/opencontainers/image-spec/pull/878
> https://github.com/opencontainers/distribution-spec/pull/309
>
> when opening this I noticed that dependabot had an alert on
> distribution-spec itself... so hopefully this will fix that.

Thanks for this. For anyone else experiencing this - bumping to any
image-spec commit that has this merge does work to quiet dependabot.

Tycho

[Vincent Batts]

Glad to hear. Thanks for Confirming.

vb