CVE-2021-41190: OCI Distribution Spec Vulnerability

CVE-2021-41190 Overview

CVE-2021-41190 is a Type Confusion vulnerability affecting the Open Container Initiative (OCI) Distribution Specification version 1.0.0 and prior. The vulnerability stems from how the specification handled Content-Type headers during push and pull operations, allowing documents containing both "manifests" and "layers" fields to be interpreted ambiguously as either a manifest or an index when no accompanying Content-Type header was present.

Critical Impact

Attackers could manipulate container image interpretation by exploiting Content-Type header inconsistencies, potentially leading to integrity issues in container deployments across affected registry implementations.

Affected Products

• Linux Foundation Open Container Initiative Distribution Specification (versions ≤ 1.0.0)
• Linux Foundation Open Container Initiative Image Format Specification
• Fedora Project Fedora (versions 34 and 35)

Discovery Timeline

• November 17, 2021 - CVE-2021-41190 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2021-41190

Vulnerability Analysis

This vulnerability represents a Type Confusion issue (CWE-843) in the OCI Distribution Specification's document type determination logic. The core problem lies in how the specification relied solely on the Content-Type header to determine whether a document should be interpreted as a manifest or an index during registry operations.

When a document contains both "manifests" and "layers" fields—or both "manifests" and "config" fields—the interpretation becomes ambiguous in the absence of a proper Content-Type header. This ambiguity creates an attack surface where the same document digest could be interpreted differently between pull operations if the Content-Type header changes.

The vulnerability affects the integrity guarantees that container registries are expected to provide. In container ecosystems, the digest serves as a content-addressable identifier that should guarantee consistent content retrieval. This vulnerability undermines that guarantee by allowing semantic interpretation to vary based on mutable header values.

Root Cause

The root cause is insufficient validation in the OCI Distribution Specification that allowed the Content-Type header to be the sole determining factor for document type interpretation. The specification lacked requirements for:

1. Mandatory mediaType field validation within manifest and index documents
2. Consistency checks between the embedded mediaType value and the Content-Type header used during operations
3. Client-side validation to reject ambiguous documents containing conflicting structural elements

Attack Vector

The attack exploits the network-accessible registry API where authenticated users with push privileges can upload ambiguous documents. An attacker could craft a malicious document that satisfies the structural requirements of both manifests and indexes, then manipulate how clients interpret the content by controlling the Content-Type header during subsequent operations.

The exploitation scenario involves:

1. An attacker pushes an ambiguous document to a registry that contains both manifest and index structural elements
2. The registry stores the document with a particular Content-Type interpretation
3. On subsequent pulls, if the Content-Type header differs, clients may interpret the document structure differently
4. This inconsistency could lead to unexpected container image layering or manifest resolution behavior

The attack requires low privileges (authenticated push access) and can have cross-scope impacts on other users pulling from the same registry. For detailed technical information, see the GitHub Security Advisory GHSA-mc8v-mgrf-8f4m.

Detection Methods for CVE-2021-41190

Indicators of Compromise

• Registry logs showing documents with inconsistent Content-Type headers across multiple pull operations for the same digest
• Container images with unusual structures containing both "manifests" and "layers" fields in the same document
• Unexpected manifest resolution behavior where image pulls return different layer configurations

Detection Strategies

• Implement registry-side validation to flag documents containing both "manifests" and "layers" fields
• Monitor for Content-Type header inconsistencies in registry access logs for the same digest
• Deploy container image scanning tools to identify ambiguous document structures before deployment
• Enable verbose logging on container runtime clients to capture Content-Type handling behavior

Monitoring Recommendations

• Configure alerting on registry APIs for documents that could be interpreted as both manifests and indexes
• Implement audit logging for all push operations to track mediaType and Content-Type relationships
• Review container deployment pipelines for any images pulled from registries running vulnerable specification versions

How to Mitigate CVE-2021-41190

Immediate Actions Required

• Update to OCI Distribution Specification version 1.0.1 or later which enforces mediaType consistency requirements
• Configure container clients to reject ambiguous documents containing both "manifests" and "layers" fields
• Audit existing registry content for potentially ambiguous documents
• Review and update container registry implementations to enforce the updated specification requirements

Patch Information

The OCI Distribution Specification has been updated to version 1.0.1, which requires that a mediaType value present in a manifest or index must match the Content-Type header used during push and pull operations. The fix was implemented in commit ac28cac0557bcd3084714ab09f9f2356fe504923. See the GitHub Distribution Spec Commit for implementation details.

Fedora has released package updates addressing this vulnerability. Users of Fedora 34 and 35 should apply available package updates through the standard update mechanisms. Multiple Fedora Package Announcements are available with detailed update information.

Workarounds

• Configure clients to distrust the Content-Type header and implement local validation of document structures
• Reject any document that contains both "manifests" and "layers" fields at the client level
• Reject documents containing both "manifests" and "config" fields to prevent ambiguous interpretation
• Implement registry admission policies to block push operations for ambiguous documents

# Example: Client-side validation recommendation
# Configure container clients to validate document structure
# Ensure mediaType field matches Content-Type header before processing
# Reject documents with ambiguous field combinations:
#   - Both "manifests" and "layers" present
#   - Both "manifests" and "config" present