A recent runc vulnerability, tracked as CVE-2024-45310, lets an attacker who can start containers with crafted volume configurations
race the runtime into creating empty files or directories on the host filesystem — and Microsoft’s MSRC entry for the CVE states that
Azure Linux “includes this open‑source library and is therefore potentially affected.” That statement is important, but it answers a narrow inventory question: it confirms Azure Linux has the implicated open‑source component in the builds Microsoft has inspected. It does not, by itself, prove that
no other Microsoft product ships the same runc binary or runtime artifact. The vendor’s wording and Microsoft’s published VEX/CSAF rollout must be read as a product‑scoped attestation and a procedural commitment to expand coverage, not an exclusivity guarantee.
Background / Overview
runc is the low-level Open Container Initiative (OCI) runtime used by container engines (containerd, Docker/Moby) to create and run containers. The bug fixed as part of CVE-2024-45310 is a race in runc’s handling of volume creation that can be abused to create empty files or directories on the host when two containers share a volume and a race with os.MkdirAll is triggered. The defect affects runc versions up to certain 1.1.x and early 1.2.x release candidates and was fixed in the patched upstream releases. Key technical facts (verified against public vulnerability indexes):
- Affected runc: versions up to 1.1.13 and some 1.2.0-rc2 and earlier ranges.
- Fixed in upstream runc releases that followed (for example 1.1.14 and subsequent patched releases).
- Practical attack prerequisites: ability to start containers with a custom volume config (local/privileged or multi‑tenant CI/infrastructure contexts). User namespaces and strict LSM policies (SELinux/AppArmor) can reduce attack scope but do not eliminate it unless properly configured.
These technical points are corroborated by NVD, distro security trackers, and vendor advisories; the CVSS and public writeups place the vulnerability in a low‑to‑medium operational impact category (host file creation/limited integrity impact rather than immediate arbitrary code execution), but the practical risk is elevated in multi‑tenant or CI/build environments where untrusted images or parallel builds are used.
What Microsoft actually published (the wording that matters)
Microsoft’s Security Response Center (MSRC) has been publishing machine‑readable CSAF and VEX attestations for third‑party open source components in Microsoft products, beginning with Azure Linux. In those VEX/CSAF documents and the MSRC update guide entries for multiple CVEs, Microsoft uses the phrasing:
“Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability.” That phrasing is an explicit product‑level inventory attestation: Microsoft inspected Azure Linux artifacts and found the implicated upstream component, so Microsoft listed Azure Linux as a product in scope for the CVE. Microsoft has also publicly committed to update the CVE/VEX attestations as it inventories additional product artifacts. Two operational takeaways from Microsoft’s wording:
- The statement is authoritative and actionable for Azure Linux customers: treat Microsoft’s attestation for Azure Linux as definitive and follow their remediation guidance for that product family.
- The statement is not a universal negative assurance for every Microsoft product or image. Absence of other Microsoft product names in the VEX/CSAF feed is absence of attestation, not proof of absence of the component elsewhere. Microsoft explicitly states it will update the VEX/CSAF records if more products are identified as carriers.
Short answer to the user question
No —
Azure Linux is not necessarily the only Microsoft product that could include runc and therefore be potentially affected by CVE‑2024‑45310. Microsoft’s MSRC line means Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) to include the implicated open‑source component, but it does not prove that no other Microsoft product or image contains runc. Other Microsoft artifacts that embed or package container runtimes — for example, AKS/VM/node images, Azure Marketplace appliances, container runtime packaging used inside managed services, or any prebuilt images and tooling Microsoft ships — could also carry the same runc versions depending on packaging and build choices, and thus remain
unverified until Microsoft inventories them or you inspect the artifacts yourself.
Why the distinction matters: practical and supply‑chain realities
- Microsoft ships multiple, distinct Linux artifacts and images.
- Azure Linux (Microsoft’s distribution lineage) — the product Microsoft started with for VEX/CSAF.
- linux‑azure kernels and kernel packages used in some VM images.
- Prebuilt images in the Azure Marketplace and partner appliances.
- AKS node images and managed node pools that may carry containerd/moby/runc packages.
- WSL2 kernel and packaged userland used on Windows developer machines (WSL instances can run container tooling depending on image content).
- Carriage depends on artifact-level packaging.
- runc is typically distributed as a binary package inside distro repositories (runc, moby‑runc, containerd’s runc deps). Different images may include different package versions or omit runc entirely if a different runtime is used. That means the presence (and version) of runc is an artifact‑level property, not a corporate‑wide binary fact.
- VEX/CSAF attestations are phased.
- Microsoft’s VEX rollout intentionally started with Azure Linux to validate the model and improve automation. That practical, phased approach speeds transparency for Azure Linux first but leaves a verification requirement for other product SKUs.
What to do: concrete verification and mitigation steps
The single most reliable way to know whether
your Microsoft‑supplied artifact is affected is to inspect that artifact directly or to consume Microsoft’s VEX/CSAF attestations as they are published. The following steps provide a prioritized, practical runbook.
1. Inventory and identify (high priority)
- List all systems and images in your environment that may run container workloads, including:
- Azure VM images, AKS nodes, and any Marketplace appliances.
- Developer machines (WSL2 users), CI/build runners, and shared builder hosts.
- Any appliance or service image provided by Microsoft that includes container tooling.
- On each host, confirm runc presence and version:
- Debian/Ubuntu: dpkg -l | grep runc ; apt policy runc
- RHEL/CentOS/Fedora: rpm -qa | grep runc ; dnf info runc
- containerd/moby installations: containerd --version ; dockerd --version ; crictl --version
- If you can run commands on the image offline, check contained packages: inspect /usr/bin/runc or package manifest.
2. Patch or replace (priority)
- For hosts running vulnerable runc versions, apply vendor updates or replace runc with a patched upstream vendor package (runc 1.1.14+ or mapped distro releases). Use your distribution’s security advisories for exact package versions.
- If vendor packages are not available, rebuild or deploy a patched runc binary from upstream and validate before production rollout.
3. Mitigations when immediate patching is impossible
- Enforce user namespaces / rootless containers where feasible — they greatly reduce the scope of what an attacker can create on the host. Note: this is not a full fix but reduces risk in many setups.
- Harden host LSM policies (SELinux/AppArmor) and container runtime confinement so runc instances run with tight labels — this can limit writable target paths. Effectiveness depends on policy completeness and has not been exhaustively tested for every scenario.
- Restrict the ability of untrusted users/tenants to launch arbitrary containers with custom volume mounts (reduce attack surface on shared builders and CI).
4. Automation and continuous validation
- Ingest Microsoft’s CSAF/VEX feeds and your distro vendor advisories into your vulnerability management pipeline to automate mapping of CVEs to the exact artifacts you run. Microsoft has published the VEX rollout blog explaining this phased approach.
- Add artifact‑level checks for runc version and package provenance to CI/CD gates and host baseline scanners (Nessus, Rapid7, Tenable rules already detect CVE-2024-45310 presence).
Risk analysis: strengths and limits of Microsoft’s attestation approach
Strengths
- Authoritative product attestation for Azure Linux — customers of Azure Linux receive a clear, machine‑readable signal to act on immediately. Microsoft’s VEX/CSAF files are designed for automation and reduce noisy triage.
- Procedural commitment — Microsoft has committed to expand attestations as inventory work completes, which improves vendor transparency over time.
Limits and potential risks
- Phased coverage introduces verification gaps. Starting with Azure Linux is pragmatic, but it means other Microsoft artifacts remain unverified until explicitly attested or inspected. Customers must not conflate absence of attestation with absence of vulnerability.
- Artifact heterogeneity. The same Microsoft company produces many different artifacts (images, kernels, appliances). Each can ship different package versions and configurations; a single attestation cannot cover this diversity until inventory work is complete.
- Operational impact in multi‑tenant environments. Even a CVE with modest CVSS (creation of empty files) can be abused in CI/CD and shared builder contexts to create surprising side effects or form part of a larger exploit chain. Prioritizing patching and confinement in those environments is essential.
How to interpret Microsoft’s pledge (“we will update the CVE to reflect this”)
Microsoft’s promise to update the CVE/VEX records
if impact to additional products is identified is procedural transparency: as Microsoft finishes per‑product inventory, it will mark additional product entries as Affected/Not Affected/Fixed in machine‑readable VEX documents. Until additional attestations appear, customers must assume other Microsoft artifacts are unverified and either:
- perform artifact‑level checks themselves; or
- ask Microsoft for explicit attestations or SBOMs for the Microsoft‑supplied artifacts they rely on.
This approach is a material improvement over opaque advisories, but it still requires active follow‑through from customers who operate diverse fleets or use many Microsoft images.
Practical examples: what to look for on systems
- Running runc check:
- /usr/bin/runc --version
- rpm -q --whatprovides /usr/bin/runc or dpkg -S /usr/bin/runc
- Container engine mapping:
- Docker/Moby often packages runc as a dependency; containerd includes its own runtime shims. Confirm the runtime component versions in Docker/containerd package metadata.
- Image and VM inspection:
- Unpack cloud images or pull Marketplace images into a sandbox and inspect included package lists (rpm -qa or dpkg --list) to find runc versions before deployment.
Implement these checks in automated discovery tooling to reduce manual triage time across a large environment.
Conclusion — what operators should do now
- Treat Microsoft’s statement about Azure Linux as an authoritative signal for Azure Linux images: if you run Azure Linux, prioritize the vendor’s remediation guidance.
- Do not assume other Microsoft products are safe simply because they are not yet listed in Microsoft’s VEX/CSAF attestations. Inventory and validate each Microsoft‑supplied artifact you run (AKS/VM images, Marketplace appliances, WSL kernels, managed service images).
- Patch runc where it is present (upgrade to upstream patched releases or distro packages), and apply mitigations (user namespaces, rootless containers, LSM confinement) on hosts that run untrusted workloads or act as shared builders.
- Automate ingestion of Microsoft’s CSAF/VEX files and distribution advisories into your vulnerability management pipeline to receive updates as Microsoft expands its attestations.
Microsoft’s transparency move — publishing VEX/CSAF and starting with Azure Linux — is a significant and welcome shift toward machine‑readable vendor attestations. It gives Azure Linux customers a fast, authoritative action point for CVE‑driven triage. However, for broad enterprise defensibility, every organization must treat that attestation as
part of an artifact‑level verification process and continue to inventory, inspect, and patch the specific Microsoft‑supplied images and hosts they run.
Source: MSRC
Security Update Guide - Microsoft Security Response Center