Pierluigi Paganini February 13, 2019

Expert discovered a privilege escalation vulnerability in default installations of Ubuntu Linux that resides in the snapd API.

Security researcher Chris Moberly discovered a vulnerability in the REST API for Canonical’s snapd daemon that could allow attackers to gain root access on Linux machines.

Canonical, the makers of Ubuntu Linux, promotes their “Snap” packages to roll all application dependencies into a single binary (similar to Windows applications).

The Snap environment includes an “app store” where developers can contribute and maintain ready-to-go packages.

“Management of locally installed snaps and communication with this online store are partially handled by a systemd service called “snapd”.”

The flaw called ‘Dirty_Sock’ would affect affects several Linux servers, the expert successfully tested on Ubuntu and released PoCs to show how to elevate privileges.

“In January 2019, I discovered a privilege escalation vulnerability in default installations of Ubuntu Linux. This was due to a bug in the snapd API, a default service. Any local user could exploit this vulnerability to obtain immediate root access to the system.” wrote the expert.

“Two working exploits are provided in the dirty_sock repository:

1. dirty_sockv1: Uses the ‘create-user’ API to create a local user based on details queried from the Ubuntu SSO.
2. dirty_sockv2: Sideloads a snap that contains an install-hook that generates a new local user.”

“Both are effective on default installations of Ubuntu.”

Canonical has already addressed the flaw, administrators need to install the snapd update to avoid the exploitation.

“Chris Moberly discovered that snapd versions 2.28 through 2.37 incorrectly validated and parsed the remote socket address when performing access controls on its UNIX socket.” reads the security advisory published by Canonical.

“A local attacker could use this to access privileged socket APIs and obtain administrator privileges. On Ubuntu systems with snaps installed, snapd typically will have already automatically refreshed itself to snapd 2.37.1 which is unaffected.”

Moberly discovered that the daemon leverages UNIX sockets to allow developers to communicate with it using a REST API.

This UNIX socket runs under the security context of the root user, so the expert investigated the possibility to elevate his privileges by abusing API methods.

The researcher discovered that it is possible to create a local user account using the daemon’s “POST /v2/create-user” API. This API command requires the program to have root permission to create a user.

The analysis of snapd connections allowed the expert to discover that if a user has root permissions, it uses a string composed of the calling pid, uid of the program connected to the socket, the socket path, and the remoteAdd (i.e. “pid=5127;uid=1000;socket=/run/snapd.socket;@”).

Where the @ substring represents the RemoteAddr of the socket, or the socket name that is used to connect to the snapd socket.

Moberly created a socket containing ;uid=0; in its name in a way to trick the parser to overwrite the uid when the string is analyzed.

Parsing a string containing the uid=0 is the last part will allow overwriting the previous uid and trick snapd into emulating a root user and allow a local user to be created.

The expert published the “dirty_sockv1” PoC code for this attack, but he pointed out that the attack required an Internet connection and the creation of an account on the Ubuntu SSO and uploading an SSH public key to your profile.

The expert also devised a Dirty_Sock version 2 that sees sideloads a malicious snap using the ‘POST /v2/snaps’ API instead.

“dirty_sockv2 instead uses the ‘POST /v2/snaps’ API to sideload a snap containing a bash script that will add a local user. This works on systems that do not have the SSH service running. It also works on newer Ubuntu versions with no Internet connection at all.” continues the expert.

“HOWEVER, sideloading does require some core snap pieces to be there. If they are not there, this exploit may trigger an update of the snapd service.”

The Dirty_Sock version 2 requires no Internet connection or the use of SSH key.

Canonical fixed the issue with the release of the 2.37.1. version that implements a stricter parser that removes user-controlled variable.

Pierluigi Paganini

(SecurityAffairs – Snapd, Ubuntu)

[adrotate banner=”5″] [adrotate banner=”13″]