9 ms·

run0 has already been exploited: https://twitter.com/hackerfantastic/status/1785495587514638559 https://twitter.com/hackerfantastic/status/17854955875146385...

by sigil 2y ago

run0 has already been exploited: https://twitter.com/hackerfantastic/status/1785495587514638559 https://twitter.com/hackerfantastic/status/17854955875146385... There will be plenty more where that came from. Yet another terrible idea and terrible implementation from Poettering.

blucaz 2y ago
That's not an exploit, that's just a sequence of basic misunderstandings about how things work on Linux. Which would be fine, nobody knows everything, if they weren't coated with grand claims and not-so-veiled personal abuse.
sfink 2y ago
Huh. I'm not at all a fan of how Poettering operates, but it's neither the ideas nor the implementation where I'd fault him. Well, it depends on what you mean by implementation, I guess; I'm talking about the core "how does it do its thing", not the interface by which you use it. I think Poettering has great ideas and great implementation. It's the execution and interface that are often terrible. If the square peg doesn't fit in the round hole, then he'll always say that the peg is perfect and the world just needs to chisel out the corners of the hole.
- sigil 2y ago
  What do you mean by "great ideas and great implementation / bad execution and bad interface." Is this a plumbing vs porcelain distinction?
  - sfink 2y ago
    Yes? Well, partly. For systemd and pulseaudio, the systems they were replacing legitimately had major problems. There were variants and workarounds that fixed some of these, but no holistic solution that I've ever heard of. There were just so many limitations if you maintained any degree of compatibility. People were (understandably) unwilling to start over and rearchitect something that desperately needed rearchitecting. Poettering designed and implemented replacements that were substantially better, and worked. Worked well, in fact. That's the great ideas & implementation part. Much of this was enabled by a willingness to throw out compatibility with nearly everything. Backwards, forwards, sideways. If I were making a bold and breaking change like this, I would sacrifice compatibility but try to make up for it by bending over backwards to catch as much of the "once working, now broken" wreckage that inevitably piled up as I could, by creating shims and compatibility stubs and transition mechanisms. I'd certainly listen to people's problems and try to work out solutions. Poettering, as far as I can tell is more of a honey badger (excuse the dated meme). He just doesn't give a shit. If your stuff doesn't work in the brave new world, then your stuff is broken and is going to have to adapt. That's the bad execution part. (Which is not to say that bending over backwards is always the right approach; it can massively increase the burden on the new system's implementer, to the point that it never happens. There's a reason why Poettering's stuff is taking over the world.) As for bad interface, this is a lot more subjective, so it's easier to disagree. But the tools to configure and use the new system are done in the style of an isolated cathedral. The tools do a ton of stuff, but they do it all in a new way, and that's great once you learn the blessed paths and internalize the new architecture. But all of your existing knowledge is now useless, and you can't flexibly combine and extend the functionality with the usual tools you'd use (bash, grep, awk, find, sort, tee....) The main functionality of the new system is not new — none of this is really adding fundamental new capabilities, it's just improving things that were already being done. But the way you interface with that functionality is all new, even though it could have been exposed in ways at least a little more unix-like and composable. Instead, the tool author determines all the things you should be doing and gives you a way to do them. If you want more or different, then you're doing something wrong. Normally, I'd expect something like this to die out as it rubbed up against the surrounding functionality. "Great system, but too much effort when we keep having to fix thing after thing." Surprisingly (to me), in systemd's case in particular, what has actually happened is that the cathedral just keeps expanding to swallow up enough of its surroundings to keep from being ejected. Maybe it's sour grapes, but my guess is that this was only possible because the previous systems were so bad. esd was a nightmare. sysvinit scripts were baroque and buggy and error-prone. Sure, the first 80% was just plain simple shell scripting. But everything did the last 20% slightly differently or just punted. It was all buggy and idiosyncratic and failed intermittently. Supposedly some of the init system variants managed to corral it all together enough to do actual dependencies and get decent startup speed, but I never used such a system. And based on the quality of the init scripts I've seen from random packages, I'm guessing the successes only happened when a relatively small group of people wrote or repaired a metric shitload of init scripts by hand. And even then, systemd provides more in its base functionality set. Architecturally, it's really quite nice.
    - throwaway7356 2y ago
      > Much of this was enabled by a willingness to throw out compatibility with nearly everything. Backwards, forwards, sideways. If I were making a bold and breaking change like this, I would sacrifice compatibility but try to make up for it by bending over backwards to catch as much of the "once working, now broken" wreckage that inevitably piled up as I could, by creating shims and compatibility stubs and transition mechanisms. I'd certainly listen to people's problems and try to work out solutions. You do realize that systemd was the only init system that offered distributions a migration path from the sysv-rc init scripts? daemontools, s6, openrc, upstart all did not have this. systemd was the only system caring about migration and backward compatibility... > Poettering, as far as I can tell is more of a honey badger As far as I know, he was the only author of an alternative init system that, for example, did actually talk to distributions to understand which problems they have. Unlike the authors of most alternatives that don't give a shit (and in turn nobody gives a shit about their init). To this day you'll find the s6 author just claim "nobody needs feature X from an init" because they themselves might not need it.
- 1oooqooq 2y ago
  you have the wrong view point. he just have a different opinion than you. he single handled managed to fool RH and all distros into turning Linux administration just like windows. systemctl list of services is so inspired by the atrocious windows' admin list of services (which have 3 fields supposed to describe the service, but they all just tell you the name again). it's no wonder his reward was a job at Microsoft. but again, he's good in all three aspects. you just disagree on building the torment Nexus that is putting Linux in the "standard certification" target for sysadmins.
  - superpatosainz 2y ago
    It's inspired by Apple's launchd.
    - 1oooqooq 2y ago
      only in it's a rewrite of the concepts from inetd but using dbus and abused for local services. which is a big part, but not the one most people complains about. the actual UX is very much windows like.
  - Analemma_ 2y ago
    I continue to be baffled at this widespread belief that Poettering somehow hoodwinked every single major Linux distro into accepting a shit product with, idk, hypnosis or something. Is it not possible that systemd is simply better than the alternatives, and the distro owners are smart enough to notice that, instead of just wrapping themselves cultish mantras about The Unix Way and how anything which resembles a design used in Windows is bad by definition? Or could that not possibly be it and he must've used mind control magic.
    - 1oooqooq 2y ago
      never said that. just that his vision was garbage, and everyone knows. but he stood by it. and nobody was putting the same energy he was to either offer better or stop it (rejecting bad ideas also take energy. see gnome deep dive into garbage as another example) Linux is mostly made from scraps (eg Bluetooth and wifi entire stacks) or misguided but funded things. the age of scratching own itch is mostly gone
mahkoh 2y ago
The linked PoC requires that the attacker already has root so that it can disable the default ptrace protection.
- blucaz 2y ago
  Requires root not just for the ptrace protection, but also to gain membership of the 'tty' group which gives control over all ttys. And then goes all surprised pikachu when it turns out that allows taking over ttys. Duh?
lofenfew 2y ago
What's the difference between this and ptracing the bash session that you run sudo under?
- nickelpro 2y ago
  None, it's a nonsense "hack"
jimrandomh 2y ago
I wouldn't worry too much about that. It's a tricky piece of security-critical software, receiving its first round of outside auditing; of course it has vulnerabilities. Sudo does have the advantage of being much more battle-tested, but that will even out with time; what will matter is how secure it is two years from now.
mananaysiempre 2y ago
To be fair, this is not at all Poettering’s idea. There is, for example, precedent in the form of s6-sudo[1], a utility from the s6 service supervisor, itself very much an anti-systemd project (except I believe it predates systemd?..). And honestly I’d be okay with a suidless Unix. For example, as best as I can tell, the only reason the kernel needs to know what executable formats even are—beyond the bare minimum needed to load PID 1—is s[ug]id binaries. [1] https://skarnet.org/software/s6/s6-sudo.html https://skarnet.org/software/s6/s6-sudo.html
- sigil 2y ago
  I like s6! One of the key differences here is that s6-sudo builds on, rather than replaces, the standard unix permissions model. s6-sudod listens on a unix domain socket. Unix domain sockets are just files, so they have an owner, group and mode bits. The answer to "who is potentially allowed to run a differently-privileged command?" is just `ls -l /path/to.sock`. For finer-grained access control, a unix domain socket listener can call `getpeereuid()` or `getsockopt(..., SO_PEERCRED, ...)` to learn who it's talking to. You can build powerful – but still relatively simple, and importantly, readily-inspectable – access control policy on top of these basic unix primitives. That's what s6 does. Look at how simple rule definition is. [0] Or, you could throw all that out the window and build something much more complex and much less inspectable, which is the systemd approach. The answer to "who is potentially allowed to run a differently-privileged command?" under `run0` is to...spend the evening reading through polkit xml rules, I guess? I realize systemd uses D-Bus, and D-Bus uses a unix domain socket. But that socket is writable by world. We're trusting polkit and complex policy xml and probably a constellation of other services to get things right after the SO_PEERCRED check. Maybe that's fine for desktop apps, but a reminder that we're talking about sudo here. Complexity is the enemy of security. The complexity of the systemd ecosystem broadly writ is how we get CVEs like this polkit privesc, which took 12 years to notice [1]. Addendum: it's possible to regard systemd as dangerously complex AND sudo as dangerously complex. OpenBSD as usual had the right idea with `doas`. [0] https://skarnet.org/software/s6/s6-accessrules-cdb-from-fs.html https://skarnet.org/software/s6/s6-accessrules-cdb-from-fs.h... [1] https://www.cvedetails.com/cve/CVE-2021-4034/ https://www.cvedetails.com/cve/CVE-2021-4034/

by sigil 2y ago

blucaz 2y ago

That's not an exploit, that's just a sequence of basic misunderstandings about how things work on Linux. Which would be fine, nobody knows everything, if they weren't coated with grand claims and not-so-veiled personal abuse.

sfink 2y ago

Huh. I'm not at all a fan of how Poettering operates, but it's neither the ideas nor the implementation where I'd fault him. Well, it depends on what you mean by implementation, I guess; I'm talking about the core "how does it do its thing", not the interface by which you use it. I think Poettering has great ideas and great implementation. It's the execution and interface that are often terrible. If the square peg doesn't fit in the round hole, then he'll always say that the peg is perfect and the world just needs to chisel out the corners of the hole.

sigil 2y ago
What do you mean by "great ideas and great implementation / bad execution and bad interface." Is this a plumbing vs porcelain distinction?
- sfink 2y ago
  Yes? Well, partly. For systemd and pulseaudio, the systems they were replacing legitimately had major problems. There were variants and workarounds that fixed some of these, but no holistic solution that I've ever heard of. There were just so many limitations if you maintained any degree of compatibility. People were (understandably) unwilling to start over and rearchitect something that desperately needed rearchitecting. Poettering designed and implemented replacements that were substantially better, and worked. Worked well, in fact. That's the great ideas & implementation part. Much of this was enabled by a willingness to throw out compatibility with nearly everything. Backwards, forwards, sideways. If I were making a bold and breaking change like this, I would sacrifice compatibility but try to make up for it by bending over backwards to catch as much of the "once working, now broken" wreckage that inevitably piled up as I could, by creating shims and compatibility stubs and transition mechanisms. I'd certainly listen to people's problems and try to work out solutions. Poettering, as far as I can tell is more of a honey badger (excuse the dated meme). He just doesn't give a shit. If your stuff doesn't work in the brave new world, then your stuff is broken and is going to have to adapt. That's the bad execution part. (Which is not to say that bending over backwards is always the right approach; it can massively increase the burden on the new system's implementer, to the point that it never happens. There's a reason why Poettering's stuff is taking over the world.) As for bad interface, this is a lot more subjective, so it's easier to disagree. But the tools to configure and use the new system are done in the style of an isolated cathedral. The tools do a ton of stuff, but they do it all in a new way, and that's great once you learn the blessed paths and internalize the new architecture. But all of your existing knowledge is now useless, and you can't flexibly combine and extend the functionality with the usual tools you'd use (bash, grep, awk, find, sort, tee....) The main functionality of the new system is not new — none of this is really adding fundamental new capabilities, it's just improving things that were already being done. But the way you interface with that functionality is all new, even though it could have been exposed in ways at least a little more unix-like and composable. Instead, the tool author determines all the things you should be doing and gives you a way to do them. If you want more or different, then you're doing something wrong. Normally, I'd expect something like this to die out as it rubbed up against the surrounding functionality. "Great system, but too much effort when we keep having to fix thing after thing." Surprisingly (to me), in systemd's case in particular, what has actually happened is that the cathedral just keeps expanding to swallow up enough of its surroundings to keep from being ejected. Maybe it's sour grapes, but my guess is that this was only possible because the previous systems were so bad. esd was a nightmare. sysvinit scripts were baroque and buggy and error-prone. Sure, the first 80% was just plain simple shell scripting. But everything did the last 20% slightly differently or just punted. It was all buggy and idiosyncratic and failed intermittently. Supposedly some of the init system variants managed to corral it all together enough to do actual dependencies and get decent startup speed, but I never used such a system. And based on the quality of the init scripts I've seen from random packages, I'm guessing the successes only happened when a relatively small group of people wrote or repaired a metric shitload of init scripts by hand. And even then, systemd provides more in its base functionality set. Architecturally, it's really quite nice.
  - throwaway7356 2y ago
    > Much of this was enabled by a willingness to throw out compatibility with nearly everything. Backwards, forwards, sideways. If I were making a bold and breaking change like this, I would sacrifice compatibility but try to make up for it by bending over backwards to catch as much of the "once working, now broken" wreckage that inevitably piled up as I could, by creating shims and compatibility stubs and transition mechanisms. I'd certainly listen to people's problems and try to work out solutions. You do realize that systemd was the only init system that offered distributions a migration path from the sysv-rc init scripts? daemontools, s6, openrc, upstart all did not have this. systemd was the only system caring about migration and backward compatibility... > Poettering, as far as I can tell is more of a honey badger As far as I know, he was the only author of an alternative init system that, for example, did actually talk to distributions to understand which problems they have. Unlike the authors of most alternatives that don't give a shit (and in turn nobody gives a shit about their init). To this day you'll find the s6 author just claim "nobody needs feature X from an init" because they themselves might not need it.
1oooqooq 2y ago
you have the wrong view point. he just have a different opinion than you. he single handled managed to fool RH and all distros into turning Linux administration just like windows. systemctl list of services is so inspired by the atrocious windows' admin list of services (which have 3 fields supposed to describe the service, but they all just tell you the name again). it's no wonder his reward was a job at Microsoft. but again, he's good in all three aspects. you just disagree on building the torment Nexus that is putting Linux in the "standard certification" target for sysadmins.
- superpatosainz 2y ago
  It's inspired by Apple's launchd.
  - 1oooqooq 2y ago
    only in it's a rewrite of the concepts from inetd but using dbus and abused for local services. which is a big part, but not the one most people complains about. the actual UX is very much windows like.
- Analemma_ 2y ago
  I continue to be baffled at this widespread belief that Poettering somehow hoodwinked every single major Linux distro into accepting a shit product with, idk, hypnosis or something. Is it not possible that systemd is simply better than the alternatives, and the distro owners are smart enough to notice that, instead of just wrapping themselves cultish mantras about The Unix Way and how anything which resembles a design used in Windows is bad by definition? Or could that not possibly be it and he must've used mind control magic.
  - 1oooqooq 2y ago
    never said that. just that his vision was garbage, and everyone knows. but he stood by it. and nobody was putting the same energy he was to either offer better or stop it (rejecting bad ideas also take energy. see gnome deep dive into garbage as another example) Linux is mostly made from scraps (eg Bluetooth and wifi entire stacks) or misguided but funded things. the age of scratching own itch is mostly gone

mahkoh 2y ago

The linked PoC requires that the attacker already has root so that it can disable the default ptrace protection.

blucaz 2y ago
Requires root not just for the ptrace protection, but also to gain membership of the 'tty' group which gives control over all ttys. And then goes all surprised pikachu when it turns out that allows taking over ttys. Duh?

lofenfew 2y ago

What's the difference between this and ptracing the bash session that you run sudo under?

nickelpro 2y ago
None, it's a nonsense "hack"

jimrandomh 2y ago

I wouldn't worry too much about that. It's a tricky piece of security-critical software, receiving its first round of outside auditing; of course it has vulnerabilities. Sudo does have the advantage of being much more battle-tested, but that will even out with time; what will matter is how secure it is two years from now.

mananaysiempre 2y ago

To be fair, this is not at all Poettering’s idea. There is, for example, precedent in the form of s6-sudo[1], a utility from the s6 service supervisor, itself very much an anti-systemd project (except I believe it predates systemd?..). And honestly I’d be okay with a suidless Unix. For example, as best as I can tell, the only reason the kernel needs to know what executable formats even are—beyond the bare minimum needed to load PID 1—is s[ug]id binaries. [1] https://skarnet.org/software/s6/s6-sudo.html https://skarnet.org/software/s6/s6-sudo.html

sigil 2y ago
I like s6! One of the key differences here is that s6-sudo builds on, rather than replaces, the standard unix permissions model. s6-sudod listens on a unix domain socket. Unix domain sockets are just files, so they have an owner, group and mode bits. The answer to "who is potentially allowed to run a differently-privileged command?" is just `ls -l /path/to.sock`. For finer-grained access control, a unix domain socket listener can call `getpeereuid()` or `getsockopt(..., SO_PEERCRED, ...)` to learn who it's talking to. You can build powerful – but still relatively simple, and importantly, readily-inspectable – access control policy on top of these basic unix primitives. That's what s6 does. Look at how simple rule definition is. [0] Or, you could throw all that out the window and build something much more complex and much less inspectable, which is the systemd approach. The answer to "who is potentially allowed to run a differently-privileged command?" under `run0` is to...spend the evening reading through polkit xml rules, I guess? I realize systemd uses D-Bus, and D-Bus uses a unix domain socket. But that socket is writable by world. We're trusting polkit and complex policy xml and probably a constellation of other services to get things right after the SO_PEERCRED check. Maybe that's fine for desktop apps, but a reminder that we're talking about sudo here. Complexity is the enemy of security. The complexity of the systemd ecosystem broadly writ is how we get CVEs like this polkit privesc, which took 12 years to notice [1]. Addendum: it's possible to regard systemd as dangerously complex AND sudo as dangerously complex. OpenBSD as usual had the right idea with `doas`. [0] https://skarnet.org/software/s6/s6-accessrules-cdb-from-fs.html https://skarnet.org/software/s6/s6-accessrules-cdb-from-fs.h... [1] https://www.cvedetails.com/cve/CVE-2021-4034/ https://www.cvedetails.com/cve/CVE-2021-4034/