THREATIST.IORead the docs 16 records in Snapd · all components
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 s…
Canonical snapd before version 2.37.1 incorrectly performed socket owner validation, allowing an attacker to run arbitrary commands as root.
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.
The snapctl component within snapd allows a confined snap to interact with the snapd daemon to take certain privileged actions on behalf of the snap.
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 snap…
A vulnerability in the seccomp filters of Canonical snapd before version 2.37.4 allows a strict mode snap to insert characters into a terminal on a 64-bit host.
snapd 2.54.2 did not properly validate the location of the snap-confine binary.
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.
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."
Race condition in snap-confine's must_mkdir_and_open_with_perms()
A race condition existed in the snapd 2.54.2 snap-confine binary when preparing a private mount namespace for a snap.
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 decl…
In snapd versions prior to 2.62, snapd failed to properly check the destination of symbolic links when extracting a snap.
cloud-init as managed by snapd on Ubuntu Core 16 and Ubuntu Core 18 devices was run without restrictions on every boot, which a physical attacker could exploit by crafting cloud-init user-data/meta-data via external medi…
In snapd versions prior to 2.62, snapd failed to properly check the file type when extracting a snap.
snapd 2.54.2 and earlier created ~/snap directories in user home directories without specifying owner-only permissions.