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.

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, 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 access to privileged information.

Last updated 24 July 2024

In some conditions, a snap package built by snapcraft includes the current directory in LDLIBRARYPATH, allowing a malicious snap to gain code execution within the context of another snap if both plug the home interface or similar. This issue affects snapcraft versions prior to 4.4.4, prior to 2.43.1+16.04.1, and prior to 2.43.1+18.04.1.

snap-confine as included in snapd before 2.39 did not guard against symlink races when performing the chdir() to the current working directory of the calling user, aka a "cwd restore permission bypass."

snap-confine in snapd before 2.38 incorrectly set the ownership of a snap application to the uid and gid of the first calling user. Consequently, that user had unintended access to a private /tmp directory.

In snapd 2.27 through 2.29.2 the 'snap logs' command could be made to call journalctl without match arguments and therefore allow unprivileged, unauthenticated users to bypass systemd-journald's access restrictions.