A local root vulnerability in glibc [LWN.net]

A local root vulnerability in glibc

Posted Oct 5, 2023 18:42 UTC (Thu) by kreijack (guest, #43513)
In reply to: A local root vulnerability in glibc by bluca
Parent article: A local root vulnerability in glibc

> IPC based as discussed here https://mastodon.social/@pid_eins/111176013718266394

I think that we have two different problems:
- the suid program with specific scope (like mount, passwd..) and yes, we could rely to a client that connect a daemon using a socket; this would reduce the attack interface
- tools like sudo/doas/pkexec that are not easy to replace.

A sudo/doas/pkexec program does "execute $command as root in the $USER environment". And the problem is "in the $USER environment" (mostly $CWD, userid, group(s)id, env....) in which $command run.
If it would be possible to clean the environment, you will not have all these sort of problem.

Instead what is done today is to do only a bit of cleanup (like ignoring LD_PRELOAD); apart that the set-uid program is run in the $USER environment.

Even assuming a syscall like please_give_me_root_capabilities_using_an_ipc(2), you still have all sort of these problems:
- the program has already used LD_PRELOAD
- anything in a (e.g.) library that uses an environment variable is still potentially exploitable...

The problem is that a SUID program relies to code (via the shared libraries or ld.so) on which it doesn't have any control. If a library change its behavior on the basis of a environment variable (but it could be a file in the current directory), it may be unknown by the program itself.

Last but not least, I did

$ find /usr/ -perm -u=s
/usr/bin/uml_net
/usr/bin/v4l-conf
/usr/bin/doas
/usr/bin/ntfs-3g
/usr/bin/fusermount3
/usr/bin/at
/usr/bin/sudo
/usr/bin/pkexec
/usr/bin/newgrp
/usr/bin/su
/usr/bin/mount
/usr/bin/umount
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/passwd
/usr/bin/pmount
/usr/bin/pumount
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
/usr/lib/xorg/Xorg.wrap
/usr/lib/chromium/chrome-sandbox
/usr/lib/polkit-1/polkit-agent-helper-1
/usr/libexec/xscreensaver/xscreensaver-auth
/usr/sbin/mount.nfs
/usr/sbin/exim4
/usr/share/skypeforlinux/chrome-sandbox
/usr/share/teams/chrome-sandbox

The latest two scary me !

A local root vulnerability in glibc

Posted Oct 5, 2023 19:54 UTC (Thu) by joib (subscriber, #8541) [Link] (1 responses)

I think a lot of sudo/doas/pkexec usage could work just as well if the env wouldn't be inherited (except maybe $CWD).

please_give_me_root_capabilities_using_an_ipc(2) doesn't sound useful; to me it sounds like it would inherit all the problems of suid. AFAICT the idea behind this ipc approach would be that the process running with elevated privileges would start from a clean slate in its own environment.

There's also file capabilities, which are a sort of limited suid:

$ getcap /usr/{bin,sbin}/*
/usr/bin/mtr-packet cap_net_raw=ep
/usr/bin/ping cap_net_raw=ep

But, it does sound a bit silly if you'd need to do some IPC in order to run something like ping in a different clean context.

A local root vulnerability in glibc

Posted Oct 6, 2023 16:43 UTC (Fri) by kreijack (guest, #43513) [Link]

> I think a lot of sudo/doas/pkexec usage could work just as well if the env wouldn't be inherited (except maybe $CWD).

This could be accomplish doing:

$ mysudo() { ssh -l root 0 "cd $PWD; $*"; }
$ mysudo "echo --- ; whoami ; echo ---; set"
root@0.0.0.0's password:
---
root
---
BASH=/usr/bin/bash
BASHOPTS=checkwinsize:cmdhist:complete_fullquote:extquote:force_fignore:globasciiranges:globskipdots:hostcomplete:interactive_comments:patsub_replacement:progcomp:promptvars:sourcepath
[...]
PWD=/home/ghigo
SHELL=/bin/bash
SHELLOPTS=braceexpand:hashall:interactive-comments
SHLVL=1
SSH_CLIENT='127.0.0.1 52998 22'
SSH_CONNECTION='127.0.0.1 52998 127.0.0.1 22'
TERM=dumb
UID=0
USER=root

A local root vulnerability in glibc

Posted Oct 6, 2023 16:19 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

> The latest two scary me !

There are some distros where it's even scarier, there's a "/snap" directory with plenty of them in different versions (thus at different vulnerability levels). A perfect playground for whoever deposits a rootkit on your system!

A local root vulnerability in glibc

Posted Oct 6, 2023 17:20 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

I wonder why those two are scarier than the third copy of `chrome-sandbox` that comes with chromium (which uses `/usr/lib/chromium` instead).