Уязвимости snapd · Страница 2

Potential denial of service in golang.org/x/crypto/ssh/agent

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

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

• Обновитесь до 2.63+22.04ubuntu0.1

snapd non-regular file indefinite blocking read

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.

• Обновитесь до 2.63+22.04ubuntu0.1

snapd allows $HOME/bin symlink

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.

• Обновитесь до 2.63+22.04ubuntu0.1

CVE-2024-5138

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. It was found that snapctl did not properly parse command-line arguments, allowing an unprivileged user to trigger an authorised action on behalf of the snap that would normally require administrator privileges to perform. This could possibly allow an unprivileged user to perform a denial of service or similar.

CVE-2022-3328

Race condition in snap-confine's must_mkdir_and_open_with_perms()

• Обновитесь до 2.57.5+22.04ubuntu0.1

CVE-2023-1523

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.

• Обновитесь до 2.58+22.04.1

CVE-2022-28948

An issue in the Unmarshal function in Go-Yaml v3 causes the program to crash when attempting to deserialize invalid input.

• Обновитесь до 2.63+22.04ubuntu0.1

CVE-2019-11840

An issue was discovered in the supplementary Go cryptography library, golang.org/x/crypto, before v0.0.0-20190320223903-b7391e95e576. A flaw was found in the amd64 implementation of the golang.org/x/crypto/salsa20 and golang.org/x/crypto/salsa20/salsa packages. If more than 256 GiB of keystream is generated, or if the counter otherwise grows greater than 32 bits, the amd64 implementation will first generate incorrect output, and then cycle back to previously generated keystream. Repeated keystream bytes can lead to loss of confidentiality in encryption applications, or to predictability in CSPRNG applications.

CVE-2017-3204

The Go SSH library (x/crypto/ssh) by default does not verify host keys, facilitating man-in-the-middle attacks. Default behavior changed in commit e4e2799 to require explicitly registering a hostkey verification mechanism.