Cloudanix VulnDB

CVE-2020-27352

Critical · 9.3

CVSS

9.3

EPSS

0.3%

Published

Jun 21, 2024

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A setup error in container management software can let processes inside a container gain more system access than intended when system services reload.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Privilege Gain
Component
Application
Class
Privilege Escalation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

snapd fails to set Delegate=yes when generating systemd service units for snaps such as docker, allowing systemd to move container-managed processes into the snap daemon's cgroup on unit reload and thereby granting unintended privileges to the container.

Why it matters to the business

Organizations running container workloads via affected snaps on Debian may face unexpected privilege escalation inside containers, increasing risk of lateral movement or data exposure; remediation urgency remains low given lack of known exploitation or ransomware use and limited EPSS score.

How an attack unfolds

An attacker with access to a container created by an affected snap triggers a systemd unit reload; because Delegate=yes is absent, systemd relocates processes into the snap's main cgroup, allowing the container to obtain additional privileges that bypass intended isolation.

How to fix it

Upgrade the linux package on Debian 11 to version 5.10.216-1 or newer; after upgrade, regenerate snap service units and verify Delegate=yes appears in the resulting systemd files.

How to confirm the fix worked

Inspect generated systemd unit files under /etc/systemd/system/snap.*.service for the presence of Delegate=yes; confirm the installed linux package version meets or exceeds 5.10.216-1 and restart affected snaps.

Typical attack path

  1. Obtain access to a container managed by the vulnerable snap
  2. Cause or wait for a systemd unit reload event
  3. Abuse the resulting cgroup relocation to escalate privileges inside the snap environment

How to detect it

Search system logs for snapd unit generation events and systemd cgroup move operations involving snap-managed services; examine audit logs for unexpected process migrations between snap cgroups.

What your security team should do

  • Apply the linux package update to 5.10.216-1 on all Debian 11 systems running affected snaps
  • Audit snap-generated systemd units for missing Delegate directives
  • Review container isolation policies and limit unnecessary snap privileges
  • Monitor EPSS and KEV updates for any future changes in exploit maturity

The record

When generating the systemd service units for the docker snap (and other similar snaps), snapd does not specify Delegate=yes - as a result systemd will move processes from the containers created and managed by these snaps into the cgroup of the main daemon within the snap itself when reloading system units. This may grant additional privileges to a container within the snap that were not originally intended.

Affected packages

Ecosystem Package Introduced Fixed
Debian:11 snapd 0 2.49-1
Debian:12 snapd 0 2.49-1
Debian:13 snapd 0 2.49-1
Debian:14 snapd 0 2.49-1
Ubuntu:16.04:LTS snapd 0 2.48.3
Ubuntu:18.04:LTS snapd 0 2.48.3+18.04
Ubuntu:20.04:LTS snapd 0 2.48.3+20.04

Related vulnerabilities