User Name Space Linux Privilege Escalation| Ubuntu 18.04 LTS | Lucideus
Introduction
As the new code is published which is capable to exploit the targeted system locally and can help the attacker to get the root privilege using the default service which is known as Unprivileged User NameSpace.
Unprivileged User Namespace
User namespaces isolate security-related identifiers and attributes, in particular, user IDs and group IDs (see credentials(7)), the root directory, keys, and capabilities. A process's user and group IDs can be different inside and outside a user namespace. In particular, a process can have a normal unprivileged user ID outside a user namespace while at the same time having a user ID of 0 inside the namespace; in other words, the process has full privileges for operations inside the user namespace but is unprivileged for operations outside the namespace.
Working of Exploit
Capabilities in the usernames allow performing the functions that requires the root privilege.
There are many privileged operations that affect resources that are not associated with any namespace type, for example, changing the system time (governed by CAP_SYS_TIME), loading a kernel module (governed by CAP_SYS_MODULE), and creating a device (governed by CAP_MKNOD). Only a process with privileges in the initial user namespace can perform such operations.
Holding CAP_SYS_ADMIN within the user namespace associated with a process's mount namespace allows that process to create bind mounts and mount the filesystems.
Holding CAP_SYS_ADMIN within the user namespace associated with a process's cgroup namespace allows that process to the mount the cgroup version 2 filesystem and cgroup version 1 named hierarchies.
Holding CAP_SYS_ADMIN within the user namespace associated with a process's PID namespace allows (since Linux 3.8) that process to mount /proc filesystems.
This exploit works on the user namespaces and other types of namespaces. It creates the namespaces defined by the command-line and makes changes in those namespaces as the required to gain the root shell.
When a non-user-namespace is created, it is owned by the user namespace in which the creating process was a member at the time of the creation of the namespace. Actions on the non-user-namespace require capabilities in the corresponding user namespace.
If CLONE_NEWUSER is specified along with other CLONE_NEW* flags in a single clone or unshare call, the user namespace is guaranteed to be created first, giving the child or caller privileges over the remaining namespaces created by the call. Thus, it is possible for an unprivileged caller to specify this combination of flags.
The NS_GET_USERNS ioctl operation can be used to discover the user namespace with which a non-user namespace is associated.
When a user namespace is created, it starts out without a mapping of user IDs (group IDs) to the parent user namespace. The /proc/[pid]/uid_map and /proc/[pid]/gid_map files expose the mappings for user and group IDs inside the user namespace for the process pid. These files can be read to view the mappings in a user namespace and written to (once) to define the mappings.
The uid_map file exposes the mapping of user IDs from the user namespace of the process pid to the user namespace of the process that opened uid_map (but see a qualification to this point below). In other words, processes that are in different user namespaces will potentially see different values when reading from a particular uid_map file, depending on the user ID mappings for the user namespaces of the reading processes.
After the creation of a new user namespace, the uid_map file of one of the processes in the namespace may be written to once to define the mapping of user IDs in the new user namespace. An attempt to write more than once to a uid_map file in a user namespace fails with the error EPERM
In a user namespace where the uid_map file has not been written, the system calls that change user IDs will fail. Similarly, if the gid_map file has not been written, the system calls that change group IDs will fail. After the uid_map and gid_map files have been written, only the mapped values may be used in system calls that change user and group IDs.
The /proc/[pid]/setgroups file displays the string "allow" if processes in the user namespace that contains the process pid are permitted to employ the setgroups system call; it displays "deny" if setgroups is not permitted in that user namespace. Note that regardless of the value in the /proc/[pid]/setgroups file (and regardless of the process's capabilities), calls to setgroups are also not permitted if /proc/[pid]/gid_map has not yet been set.
A privileged process (one with the CAP_SYS_ADMIN capability in the namespace) may write either of the strings "allow" or "deny" to this file before writing a group ID mapping for this user namespace to the file /proc/[pid]/gid_map. Writing the string "deny" prevents any
process in the user namespace from employing setgroups.
When a process inside a user namespace executes a set-user-ID (set-group-ID) program, the process's effective user (group) ID inside the namespace is changed to whatever value is mapped for the user (group) ID of the file. However, if either the user or the group ID of the file has no mapping inside the namespace, the set-user-ID (set-group-ID) bit is silently ignored: the new program is executed, but the process's effective user (group) ID is left unchanged.
When a process's user and group IDs are passed over a UNIX domain socket to a process in a different user namespace, they are translated into the corresponding values as per the receiving process's user and group ID mappings.
Video PoC
