snapd will follow archived symlinks when unpacking a filesystem
In snapd versions prior to 2.62, snapd failed to properly check the
destination of symbolic links when extracting a snap. The snap format
is a squashfs file-system image and so can contain symbolic links and
other file types. Various file entries within the snap squashfs image
(such as icons and desktop files etc) are directly read by snapd when
it is extracted. An attacker who could convince a user to install a
malicious snap which contained symbolic links at these paths could then
cause snapd to write out the contents of the symbolic link destination
into a world-readable directory. This in-turn could allow an unprivileged
user to gain ac
In snapd versions prior to 2.62, snapd failed to properly check the file
type when extracting a snap. The snap format is a squashfs file-system
image and so can contain files that are non-regular files (such as pipes
or sockets etc). Various file entries within the snap squashfs image
(such as icons etc) are directly read by snapd when it is extracted. An
attacker who could convince a user to install a malicious snap which
contained non-regular files at these paths could then cause snapd to block
indefinitely trying to read from such files and cause a denial of service.
In snapd versions prior to 2.62, when using AppArmor for enforcement of
sandbox permissions, snapd failed to restrict writes to the $HOME/bin
path. In Ubuntu, when this path exists, it is automatically added to
the users PATH. An attacker who could convince a user to install a
malicious snap which used the 'home' plug could use this vulnerability
to install arbitrary scripts into the users PATH which may then be run
by the user outside of the expected snap sandbox and hence allow them
to escape confinement.
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.
Using the TIOCLINUX ioctl request, a malicious snap could inject contents into the input of the controlling terminal which could allow it to cause arbitrary commands to be executed outside of the snap sandbox after the snap exits. Graphical terminal emulators like xterm, gnome-terminal and others are not affected - this can only be exploited when snaps are run on a virtual console.
USN-5292-1 fixed a vulnerability in snapd. Unfortunately that update introduced
a regression that could break the fish shell. This update fixes the problem.
We apologize for the inconvenience.
Original advisory details:
James Troup discovered that snap did not properly manage the permissions for
the snap directories. A local attacker could possibly use this issue to expose
sensitive information. (CVE-2021-3155)
Ian Johnson discovered that snapd did not properly validate content interfaces
and layout paths. A local attacker could possibly use this issue to inject
arbitrary AppArmor policy rules, resulting in a bypass of intended acc
snapd could be made to bypass intended access restrictions through snap content interfaces and layout paths
snapd 2.54.2 fails to perform sufficient validation of snap content interface and layout paths, resulting in the ability for snaps to inject arbitrary AppArmor policy rules via malformed content interface and layout declarations and hence escape strict snap confinement. Fixed in snapd versions 2.54.3+18.04, 2.54.3+20.04 and 2.54.3+21.10.1
snapd could be made to escalate privileges and run programs as administrator
snapd 2.54.2 did not properly validate the location of the snap-confine binary. A local attacker who can hardlink this binary to another location to cause snap-confine to execute other arbitrary binaries and hence gain privilege escalation. Fixed in snapd versions 2.54.3+18.04, 2.54.3+20.04 and 2.54.3+21.10.1
snapd 2.54.2 and earlier created ~/snap directories in user home directories without specifying owner-only permissions. This could allow a local attacker to read information that should have been private. Fixed in snapd versions 2.54.3+18.04, 2.54.3+20.04 and 2.54.3+21.10.1
snapd could be made to escalate privileges and run programs as administrator
A race condition existed in the snapd 2.54.2 snap-confine binary when preparing a private mount namespace for a snap. This could allow a local attacker to gain root privileges by bind-mounting their own contents inside the snap's private mount namespace and causing snap-confine to execute arbitrary code and hence gain privilege escalation. Fixed in snapd versions 2.54.3+18.04, 2.54.3+20.04 and 2.54.3+21.10.1
Sandbox escape vulnerability via snapctl user-open (xdg-open)
It was discovered that snapctl user-open allowed altering the $XDG_DATA_DIRS environment variable when calling the system xdg-open. OpenURL() in usersession/userd/launcher.go would alter $XDG_DATA_DIRS to append a path to a directory controlled by the calling snap. A malicious snap could exploit this to bypass intended access restrictions to control how the host system xdg-open script opens the URL and, for example, execute a script shipped with the snap without confinement. This issue did not affect Ubuntu Core systems. Fixed in snapd versions 2.45.1ubuntu0.2, 2.45.1+18.04.2 and 2.45.1+20.04.2.