A local privilege-escalation vulnerability in Canonical’s snapd package has been uncovered, which would allow any user to obtain administrator privileges and immediate root access to affected Linux system servers.
Snapd is used by Linux users to download and install apps in the .snap file format. Chris Moberly at Missing Link Security found the issue (CVE-2019-7304), and said that it resides in the snapd API. This is installed by default in Ubuntu; Moberly said in his bug report that his proof-of-concept exploits work “100% of the time on fresh, default installations of Ubuntu Server and Desktop.” He also noted that the flaw is “likely included in many Ubuntu-like Linux distributions.”
Taking a page from the well-known “Dirty Cow” vulnerability, Moberly dubbed the issue “Dirty Sock,” since it revolves around handling sockets.
“snapd versions 2.28 through 2.37 incorrectly validated and parsed the remote socket address when performing access controls on its UNIX socket,” Canonical explained in its Ubuntu advisory, which provides patches for affected packages. “A local attacker could use this to access privileged socket APIs and obtain administrator privileges.”
Moberly elaborated in a blog post explaining the technical details of the issue. “snapd serves up a REST API attached to a local UNIX_AF socket. Access control to restricted API functions is accomplished by querying the UID associated with any connections made to that socket. User-controlled socket peer data can be affected to overwrite a UID variable during string parsing in a for-loop. This allows any user to access any API function.”
With access to the API, there are multiple methods to obtain root. The researcher developed PoCs for two of them that involve creating root-level user accounts; but there are likely many more approaches that could be taken, he noted.
The first, dirty_sockv1, bypasses access control checks to use a restricted API function (POST /v2/create-user) of the local snapd service. “This queries the Ubuntu SSO for a username and public SSH key of a provided email address, and then creates a local user based on these values,” Moberly explained.
The down side is that successful exploitation requires an outbound Internet connection and an SSH service accessible via localhost.
The second, appropriately named dirty_sockv2, also bypasses access control checks of the local snapd service to use a restricted API function, this time POST /v2/snaps. “This allows the installation of arbitrary snaps,” the researcher said. “Snaps in ‘devmode’ bypass the sandbox and may include an install hook that is run in the context of root at install time. dirty_sockv2 leverages the vulnerability to install an empty ‘devmode’ snap including a hook that adds a new user to the local system. This user will have permissions to execute sudo commands.”
As opposed to version one, dirty_sockv2 does not require the SSH service to be running. It will also work on newer versions of Ubuntu with no Internet connection at all, making it resilient to changes and effective in restricted environments.
Exploit two is also effective on non-Ubuntu systems that have installed snapd but that do not support the “create-user” API that the first exploit leverages.
Moberly found the vulnerability in January, and praised the snapd team fixing the issue quickly. “I was very impressed with Canonical’s response to this issue,” he said. “The team was awesome to work with, and overall the experience makes me feel very good about being an Ubuntu user myself.”
On Ubuntu systems with snaps installed, snapd “typically will have already automatically refreshed itself to snapd 2.37.1 which is unaffected,” Canonical said. As for other Linux distros that use snapd, such as Linux Mint, Debian and Fedora, administrators should check to see if the flaw is present and apply patches accordingly.
