Linux Kernel USERNS Issues

Credit: halfdog
Risk: Medium
Local: Yes
Remote: No

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello List, Here are some issues recently discovered: * Overlayfs over Fuse Privilege Escalation: On some systems, e.g. Ubuntu Wily, it is possible to place an USERNS overlayfs mount over a fuse (file system in userspace) mount. Inactive SUID binaries in the user-controllable fuse filesystem may then be copied to other filesystems in copy_up, thus allowing unprivileged users to create arbitrary SUID binaries on the disk. Read more... (CRD 20160222) * User Namespaces Overlayfs Xattr Setgid Privilege Escalation: Overlayfs allows to mix content of two filesystems, e.g. read-only medium with r/w RAM-fs. This is also allowed within user namespaces. As overlayfs does not initialize xattr ACLs when copying files, malicious user may gain write access to SGID directories and further gain full member access to that group. As member of group root or staff escalation to user root might be simple. (CRD 20160222) * Access to all /dev/pts devices via pt_chown and user namespaces: /usr/lib/pt_chown was used to change ownership of slave pts devices in /dev/pts to the same uid holding the master file descriptor for the slave. Another devpts instance mountend within user namespace allows unprivileged user to fool pt_chown to operate on file descriptors from inside namespace but change ownership of device with same number outside the namespace. (Issue too old, no clear fix on the way - see oss-security discussion.) * Aufs Union Filesystem Privilege Escalation In User Namespaces: Aufs is a union filesystem to mix content of different underlying filesystems, e.g. read-only medium with r/w RAM-fs. That is also allowed in user namespaces when module was loaded with allow_userns option. Due to different bugs, aufs in a crafted USERNS allows privilege escalation, which is a problem on systems enabling unprivileged USERNS by default, e.g. Ubuntu Wily. (This is fixed upstream, but not merged in to kernel mainline. As issue not so critical and nearly identical to one below, better FD to let user protect ...) hd - -- PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlbMFMgACgkQxFmThv7tq+699QCgk0+iF9HH++T16vf1PC3s5E1o nCoAoIT6vULxdxA8nQaj3sCjwCFKLxmH =ci4J -----END PGP SIGNATURE-----


Vote for this issue:


Thanks for you vote!


Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.

(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2019,


Back to Top