A local root vulnerability in glibc [LWN.net]

A local root vulnerability in glibc

Posted Oct 3, 2023 19:20 UTC (Tue) by fraetor (subscriber, #161147) [Link]

It really is a week of vulnerabilities.

A local root vulnerability in glibc

Posted Oct 3, 2023 20:44 UTC (Tue) by iustin (subscriber, #102433) [Link] (7 responses)

If I read correctly, this applies to startup of setuid binaries, so just updating libc6 should be enough, right?

A local root vulnerability in glibc

Posted Oct 3, 2023 21:21 UTC (Tue) by siddhesh (subscriber, #64914) [Link]

Yes, updating glibc should be enough. The fix has been backported all the way to 2.34 in the upstream release branches.

A local root vulnerability in glibc

Posted Oct 4, 2023 12:49 UTC (Wed) by smoogen (subscriber, #97) [Link] (5 responses)

As long as the setuid program dynamically links to libc. If it is statically built which some setuid are done then the setuid program will need to be recompiled.

A local root vulnerability in glibc

Posted Oct 4, 2023 19:47 UTC (Wed) by iustin (subscriber, #102433) [Link] (4 responses)

Oh, I now realise my question was misunderstood.

I meant, it is enough to update libc6 without rebooting/restarting daemons, or do you need a full reboot? Since the vulnerability appears at ld.so/dynamic loading time, it appears that simply updating libc6 is enough.

It is of course obvious that statically linked binaries are never fixed by updating a shared library.

Running programs are not affected by updating their files

Posted Oct 5, 2023 8:34 UTC (Thu) by sdalley (subscriber, #18550) [Link] (3 responses)

It's not enough. A running program exists in memory or swap, and does not magically change just because its executable files or libraries have updated on disk. Any program which links to a library that was vulnerable will need to be terminated and restarted.

Running programs are not affected by updating their files

Posted Oct 5, 2023 8:38 UTC (Thu) by geert (subscriber, #98403) [Link] (2 responses)

In general, that is indeed true.
For this particular case, where the vulnerability is in the loader evaluating the GLIBC_TUNABLES environment variable, I guess the program is no longer vulnerable after it has been started.

Running programs are not affected by updating their files

Posted Oct 5, 2023 11:51 UTC (Thu) by hmh (subscriber, #3838) [Link] (1 responses)

It all depends on what gets used for the dynamic loader on a running process. execve() should be fine, the kernel would load the newer, fixed dynamic linker anyway.

And if your environment is currently safe, only applications that allow changing it and which do something weird in userspace with a cached copy of ld.so might need a restart. Maybe dlopen()?

Running programs are not affected by updating their files

Posted Oct 5, 2023 12:45 UTC (Thu) by iustin (subscriber, #102433) [Link]

Exactly, I was referring to this specific issue, not in general.

A local root vulnerability in glibc

Posted Oct 4, 2023 5:36 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (10 responses)

I'm going to assume this is, essentially, yet another instance of "we found a weird way of breaking setuid binaries." (Checks link.) Yep, exactly as I thought.

Honestly, I'm starting to find it hard to get excited by these vulns. Ideally, setuid binaries would just stop existing altogether, but we can't have nice things. More realistically, untrusted users should be confined to a container and/or VM (preferably both), which is itself treated as untrusted. Containers definitely don't need to have setuid binaries, and with some effort you can probably get to that point with a VM as well.

(And yes, this is infeasible for a shared family computer. But that's going to get pwned no matter what operating system you install on it, so you may as well admit defeat and just give the five-year-old root anyway.)

A local root vulnerability in glibc

Posted Oct 4, 2023 7:27 UTC (Wed) by Sesse (subscriber, #53779) [Link] (4 responses)

There's been work to remove the setuid status from a typical installation, but it's sort of hard to sandbox su or sudo?

A local root vulnerability in glibc

Posted Oct 4, 2023 18:31 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (3 responses)

Unfortunately, pkexec also requires setuid, or else I would tell you to use that. But in general, the "proper" way to do this is something like polkit+systemd+(whatever PAM-related nonsense you use for authn). In other words, you ask a privileged daemon (systemd in practice) to launch some command on your behalf, and the daemon consults system policy (polkit) to determine whether you are authorized to do it. There's also a PAM integration, but I have no idea how that works, because I don't make a habit of delving into the Linux necronomicon more often than strictly necessary. I tend to assume that a typical installation would prompt you to enter a password or other credential before proceeding.

A local root vulnerability in glibc

Posted Oct 5, 2023 12:36 UTC (Thu) by hmh (subscriber, #3838) [Link] (1 responses)

As if the polkit and friends security surface is any smaller and more defended than glibc's complicated mess of a dynamic loader. Security issues are not unknown in that space, either. And it is way too complicated, even harder to use correctly than suid/sgid.

The correct answer here is more likely to be in he direction of: keep suid and sgid around and use it where possible while nothing better and safer like capabilities are available for what you need. But do that while actually hardening for real the dynamic linker without weakening security for any reason. No debugging, no behaviour modification based on the environment.

Then, one would need a separate, object-build-time thing for debugging suid/sgid binaries that cannot be in any way shoehorned into a production suid or sgid binary, instead. More annoying to developers, but that much safer for everyone.

A local root vulnerability in glibc

Posted Oct 5, 2023 18:15 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

Well, IMHO the *real* real option is just "don't elevate your privileges at all." If you want something to happen at a higher security level, you configure systemd to do it when you're building the image. Then you don't need to do any runtime checks at all, and nothing from a lower privilege level ever asks a higher privilege level to do anything.

But people don't like it when I tell them that (presumably because they don't like containers and/or VMs), so I have to provide some kind of alternative. You're right that polkit is not ideal, but it is the project that actually exists in this space. If you can point me to a better one, I'll gladly start recommending that instead.

> But do that while actually hardening for real the dynamic linker without weakening security for any reason. No debugging, no behaviour modification based on the environment.

I consider this less than ideal for one very simple reason: Traditionally, the rule has been that the child process inherits the uid of its parent, and so it was assumed that the parent could not attack the child (they're both the same user). Many process parameters are therefore inherited over a fork/exec, and this is widely used in practice for process configuration. Shells, for instance, are heavily dependent on being able to reconfigure a child process between fork and exec. Setuid breaks this assumption, and creates a security boundary in a very inconvenient location, so you end up having to go through the entire list of process configuration variables and manually deny all the ones that are likely to cause problems. Security should be based on allowlisting, not denylisting, and so I consider it a fundamentally flawed approach.

A local root vulnerability in glibc

Posted Oct 5, 2023 13:24 UTC (Thu) by job (guest, #670) [Link]

Please do not suggest polkit in a security context. It is an under maintained mess with a huge surface area, and has had some nasty vulnerabilities over the years. We need something more easily audited than sudo, which also have had a number of problems while being an order of magnitude less complex than polkit.

A local root vulnerability in glibc

Posted Oct 4, 2023 7:45 UTC (Wed) by taladar (subscriber, #68407) [Link] (4 responses)

The idea of a trusted user is deeply flawed. Any user can easily become untrusted if someone exploits a remote code execution vulnerability or gets them to open a file exploiting a parser in some application they use.

A local root vulnerability in glibc

Posted Oct 4, 2023 17:00 UTC (Wed) by mokki (subscriber, #33200) [Link] (1 responses)

Or a developer just runs npm install or pip install, both of which download transitively a number of dependencies any of which can be modified to run whatever commands they want to on the system.
Previously the packages could "only" install upload users secrets. With this vulnerability they can take over the whole system.

A local root vulnerability in glibc

Posted Oct 4, 2023 17:21 UTC (Wed) by mb (subscriber, #50428) [Link]

Taking over the whole system vs. taking over the user's account is largely the same thing for the vast majority of personal machines.

I don't care, if somebody takes my /usr/bin/bash and uploads it to somewhere. I don't even care that much, if some attacker deletes my /usr/bin/bash. And I don't care that much, if the attacker replaces /usr/bin/bash with malware. Everything is lost already anyway.

The problem is if somebody gains access to my /home/user. And that happens at the point where I download and execute malicious programs. Not where these programs exploit a setuid vulnerability.

A local root vulnerability in glibc

Posted Oct 4, 2023 18:16 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

Hence why the workstation use case is hopeless anyway. Users (like, actual real humans, not entries in /etc/passwd) do not like to be told "sorry, you're not trusted to do that." So you either have locked-down hardware or trusted users. Pick your poison.

A local root vulnerability in glibc

Posted Oct 4, 2023 19:24 UTC (Wed) by mat2 (guest, #100235) [Link]

When it comes to consumer devices, there is no higher authority then the device owner. When the user is not trusted, you end up with a DRM (Digital Restrictions Management) system.

A local root vulnerability in glibc

Posted Oct 4, 2023 6:03 UTC (Wed) by Kamiccolo (subscriber, #95159) [Link]

Putting an emphasize:
> although we discovered this buffer overflow manually,
> we later tried to fuzz the vulnerable function, parse_tunables(); both
> AFL++ and libFuzzer re-discovered this overflow in less than a second,
> when provided with a dictionary of tunables (which can be compiled by
> running "ld.so --list-tunables").

*sigh*

A local root vulnerability in glibc

Posted Oct 4, 2023 10:40 UTC (Wed) by bluca (subscriber, #118303) [Link] (21 responses)

We really need to yeet setuid binaries into the sun

A local root vulnerability in glibc

Posted Oct 4, 2023 16:39 UTC (Wed) by eduperez (guest, #11232) [Link] (20 responses)

What is the alternative (serious question)?

A local root vulnerability in glibc

Posted Oct 4, 2023 17:24 UTC (Wed) by bluca (subscriber, #118303) [Link] (19 responses)

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

A local root vulnerability in glibc

Posted Oct 5, 2023 6:12 UTC (Thu) by joib (subscriber, #8541) [Link] (12 responses)

I'm not an expert, but from reading on the topic over the years my rough conclusion is that if we started to design an OS from a clean sheet today we'd start with a capability based security design (well, might even apply to hardware level protections via things like CHERI etc. instead of traditional virtual memory based isolation). And in such a design, crucially, you can only drop capabilities, not gain additional ones. So in a way, when the system boots, the OS kernel has some kind of root capability, from which it can dole out subsets to other parts of the kernel, user space processes etc. In order to (temporarily) get more capabilities, as increasing capabilities is verboten, one would need to acquire a higher capability context via some form of authentication.

Of course, in reality zillions of $$$ are invested in current OS'es and applications that run on them, and a clean sheet design is but a dream. So the problem becomes how to somehow approximate that without massively breaking the existing system. And yes, "yeeting suid/fcaps into the sun" is probably a big part of it. As for how to temporarily get the higher capabilities, yes some form of IPC might be the practical solution. Or ssh to a local socket or such. And the NNP flag for tasks could probably help as well. Come to think of it, that would also allow jettisoning all this ruid/euid/suid stuff as superfluous.

A local root vulnerability in glibc

Posted Oct 5, 2023 7:52 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (1 responses)

You start with the ideal security mantra 'only drop capabilities', then you realise you need most of those capabilities at one time or another for a long running system (as opposed to a toy that boots 2h in a lab), then either you admit your original goal is flawed or you ask via IPC something that was not foolish enough to drop caps to do whatever is needed.

So basically your billions of billions of software rewrite only move you from "you need to fool something able to elevate privileges to do evil" to "you need to fool something that runs permanently with elevated privileges to do evil". And you get a nice fat IPC channel that does not exist in the first scenario to accomplish this.

Of course in the first prototypes the IPC channel is small and easy to control, once you’ve shoved all the use cases that require privilege escalation today inside who actually thinks it will stay small and easy to control?

A local root vulnerability in glibc

Posted Oct 5, 2023 7:56 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

Not that privilege separation is bad, it is very nice when done properly (see postfix), but it is awfully hard to do properly at scale for a whole system, because that requires deep thought on where each privilege is actually needed.

A local root vulnerability in glibc

Posted Oct 5, 2023 22:46 UTC (Thu) by shemminger (subscriber, #5739) [Link] (8 responses)

Intel tried building an OS with capabilities and HW support back in the 1990's.
In addition to biting off to big a task, what did run was incredibly slow an never made it out to the public. They invested lots of money at the time.

A local root vulnerability in glibc

Posted Oct 6, 2023 8:39 UTC (Fri) by geert (subscriber, #98403) [Link] (2 responses)

Which does not mean it is not feasible now, only that it was not feasible in the nineties.

During development, Intel simulated the 80386 at the gate level on an IBM mainframe, which was rumoured to take one week to boot DOS. Nowadays we boot simulated Linux-on-LiteX-VexRiscv using Verilator on our desktops in minutes.

A local root vulnerability in glibc

Posted Oct 6, 2023 14:46 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> simulated the 80386 at the gate level on an IBM mainframe, which was rumoured to take one week to boot DOS.

Bear in mind the architecture differences between a micro-processor and a mainframe. Mainframe CPUs were (maybe still are) slow even by their contemporary standards. The whole point of a mainframe is that the machine is mostly co-processors, which do most of the work.

I remember the days when they attempted to port Pr1mos to Intel - so the story goes it was a disaster. The 50-series CPU relied on the segmented virtual memory architecture, and the 80386 (I think that was the chip) was hopeless.

So no, I don't believe it wasn't feasible in the 90s. It was just that the x86 architecture was sweeping everything else away (thanks to the IBM PC), and all the awful design decisions that went into it effectively hindered and hamstrung a lot of far more superior work. As usual, "cheap but crap" won the battle, but cost us the dear.

Cheers,
Wol

A local root vulnerability in glibc

Posted Oct 6, 2023 17:11 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

IBM have, in recent years, been more than happy to boast that their mainframe CPU cores, of themselves, are the fastest microprocessors in the business :)

Intel iAPX432

Posted Oct 8, 2023 8:05 UTC (Sun) by CChittleborough (subscriber, #60775) [Link] (4 responses)

If you mean the Intel iAPX432, it was created in the 1980s. It was a fairly vertical microprogram with enormous amounts (for the day) of microcode on chip. That microcode provided an ISA which was a superset of what Ada needed: a multitasking operating system with capabilities and concurrent garbage collection in Silicon. One of the superset features was that a called procedure could survive returning to the caller, like call/cc in Lisp. To do this, the microcode had to allocate the frame for each called procedure on the stack. When they got it running, they found that it could do 50 procedure calls per second: a bare procedure call took an average of 20 ms.

Wikipedia has a relatively decent article on this, though it leaves out the 50 calls/sec bit (which I heard in a talk by Prof Ed Gehringer).

Intel iAPX432

Posted Oct 8, 2023 8:07 UTC (Sun) by CChittleborough (subscriber, #60775) [Link]

Err, the point I meant to make is that I do not think the capability addressing was the main problem with the 432.

Intel iAPX432

Posted Oct 8, 2023 14:03 UTC (Sun) by jem (subscriber, #24231) [Link] (1 responses)

To be precise, the project was started in 1976, and the product was launched in 1981. Meanwhile, to defend against competitors like Motorola and Zilog, Intel introduced the 8086 as a stopgap solution. We all know what happened after that.

From the Wikipedia article: "The iAPX 432 instructions have variable length, between 6 and 321 bits." Maybe partially as a reaction to this madness, something else was emerging from Berkeley: RISC. Roughly at the same time, in popular music, psychedelic progressive rock was replaced by punk rock.

Intel iAPX432

Posted Oct 9, 2023 2:17 UTC (Mon) by CChittleborough (subscriber, #60775) [Link]

Thanks for correcting me about the dates. Thanks also for the memorable, amusing and insightful analogy between RISC and punk rock!

Intel iAPX432

Posted Oct 9, 2023 9:02 UTC (Mon) by james (subscriber, #1325) [Link]

There is a fascinating oral history interview with Bob Colwell, senior architect on the Pentium Pro and the Pentium 4. He says (PDF, sorry) that in 1984:

...we went up to this bar where I struck up a conversation with some random guy I didn't know sitting next to me. He asked me what I was doing at Intel for the summer. I said "I'm a grad student doing some research on the 432." "Really? What kinds of things are you finding?" I said "Well, I'm finding that there's a huge disconnect between the software and the hardware. I mean the hardware should be capable of doing a procedure call much quicker than it's actually doing, for instance, it's taking many hundreds of clock cycles. And in other places, I'm seeing all kind of wastage from the compiler just setting variables that never get used, classic stuff you just don't do." And the guy said "Really? I mean tell me more about that part."
Eventually, I said "Okay, who are you? You know way too much about this technology." He tells me "I'm the leader of the compiler team." And I said "In that case I probably just fatally offended you." He said "No, not at all because I know we generate bad code and I don't care." He said "We don't like the 432 hardware team." And I thought "Oh my God, there is no hope that this project is going to work when you have the two main casts killing each other." He said "That hardware team never listened to us compiler folks At some point we decided that we'd live up to the letter of the contract but beyond that? No."

and

Well somewhere along the way, they threw away a little bit too much performance, and if they had been paying attention to that aspect of it, I think that they could have fixed those pieces, and if they made peace with the compiler guys they could have fixed that part of it too. They could have actually got within shouting distance of a competitive part. But, as it was, there were so many mistakes that there was no way to recover from them all.

It's a fascinating read.

A local root vulnerability in glibc

Posted Nov 18, 2023 1:48 UTC (Sat) by Rudd-O (guest, #61155) [Link]

Genode does exactly this. And it can run Linux in a VM. All drivers are in user space and none have more privileges than the absolutely required.

Genode is truly cool. Give it a spin.

A local root vulnerability in glibc

Posted Oct 5, 2023 18:42 UTC (Thu) by kreijack (guest, #43513) [Link] (5 responses)

> 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:05 UTC (Thu) by adobriyan (subscriber, #30858) [Link]

> /usr/bin/cnpkmoduleufr2r

UFR II/UFRII LT Printer Driver for Linux V5.70.

What could _possibly_ go wrong?

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).