CVE-2024-5138: Input Validation
Impact
A snap with prior permissions to create a mount entry on the host, such as firefox, normally uses the permission from one of the per-snap hook programs. A unprivileged users cannot normally trigger that behaviour by using snap run --shell firefox followed by snapctl mount, since snapd validates the requesting user identity (root or non-root). The issue allows unprivileged users to bypass that check by crafting a malicious command line vector which confuses snapd into thinking the help message is requested.
Unprivileged user on a default installation of Ubuntu, where firefox is as provided as a snap, may cause a denial-of-service attack by repeatedly mounting hunspell database over and over and eventually exhausting system memory.
Other attacks, reliant on the same underying mechanism (mount), are possible. In all cases the snap must be installed and grated permission to perform this action (by connecting an appropriate snap interface), which requires administrative privileges. As such we are focusing on the case of default installation where an unprivileged user may exploit this behavior.
Patches
Patch: https://github.com/canonical/snapd/commit/68ee9c6aa916ab87dbfd9a26030690f2cabf1e14 Release: Available from Snapd 2.64
Workarounds
Users may disconnect any instances of the mount-control interface to prevent snapd from creating such mount points. For example, the firefox snap has the host-hunspell plug, which is of type mount-control. The interface can be disconnected with:
sh sudo snap disconnect firefox:host-hunspell
References
The original bug report was made on Launchpad: https://bugs.launchpad.net/snapd/+bug/2065077 CVE.org: https://www.cve.org/CVERecord?id=CVE-2024-5138 Canonical: https://ubuntu.com/security/CVE-2024-5138
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/snapcore/snapdto a version that resolves this vulnerability.Fixed in 0.0.0-20240524114846-68ee9c6aa916 - Upgrade
Upgrade
go/github.com/snapcore/snapdto a version that resolves this vulnerability.Fixed in 2.63.1 - Upgrade
Upgrade
debian/snapdto a version that resolves this vulnerability.Fixed in 2.66.1-2Fixed in 2.67-1 - Upgrade
Upgrade
snapdto a version that resolves this vulnerability.Fixed in 2.64Patch 68ee9c6aa916ab87dbfd9a26030690f2cabf1e14 - Configuration
Disconnect the mount-control interface instance for the firefox snap to prevent snapd from creating hunspell mount points: run `sudo snap disconnect firefox:host-hunspell`.
snapd (snap interface) firefox:host-hunspell (mount-control interface) = disconnected
Event History
Frequently Asked Questions
What is the severity of CVE-2024-5138?
CVE-2024-5138 has a moderate severity level due to its potential to escalate privileges through improper handling of mount permissions.
How do I fix CVE-2024-5138?
To fix CVE-2024-5138, update to the latest version of snapd as specified in the remediation instructions for your specific package.
Who is affected by CVE-2024-5138?
Users of snapd versions between 2.51.6 and 2.63.1, as well as earlier versions of the package, are affected by CVE-2024-5138.
What is the impact of CVE-2024-5138?
The impact of CVE-2024-5138 allows unprivileged users to potentially create mount entries on the host system, leading to privilege escalation.
Is there a workaround for CVE-2024-5138?
There is no official workaround for CVE-2024-5138; the only resolution is to update to a patched version.