Thread by @hackerfantastic

Lennart Poettering intends to replace "sudo" with systemd's run0. Here's a quick PoC to demonstrate root permission hijacking by exploiting the fact "systemd-run" (the basis of uid0/run0, the sudo replacer) creates a user owned pty for communication with the new "root" process.

This isn't the only bug of course, it's not possible on Linux to read the environment of a root owned process but as systemd creates a service in the system slice, you can query D-BUS and learn sensitive information passed to the process env, such as API keys or other secrets.

I have only spent a little bit of time digging through the new implementation, I do not see how it is "safer" or more "secure" than existing SUID "sudo" or "su" implementations. It certainly seems to add additional attack surface to Linux as every sudo command is a service.

The exploit above works by hijacking the master end of the pty from the process which is communicating with the root process, it uses "reptyr" - a tool for doing these attacks which were common on UNIX in the 90's. This is just quick demo to highlight replacing sudo ends poorly.

@DPA168 @pid_eins I'm not bothering to weaponize this exploit as I'm using it to point out that systemd is undoing decades of UNIX philosophy and security engineering. Linux is not UNIX but it becomes less UNIX like every day under systemd.

@edu4rdshl @skid9000 Understand the actual bug and then you'll understand the example exploit more easily. Its not the only way todo it but as I don't work for systemd and find the maintainer to be an ass, I'm not giving this further time. Use it if you want, I won't use distros that adopt it.

@ProgrammerDude @pid_eins I fully understand its returning the properties in the .service file that *every* command run under their "sudo" replacement will create.

@ProgrammerDude @pid_eins

"systemd-run --pipe" will reuse your user owned pty with the root process and "systemd-run --pty" will create a new root-owned one but root terminal still accessible through the local user pty. Ptrace used for PoC only to hijack the tty fully. tty/sys gid are not required.

@pid_eins Similarly if you don't understand that subsystem like ptrace is frequently used by Linux users and just one quick method to reparent a process between tty's to demo a PoC, then I have little further to discuss with you. All future exploits of mine in systemd will be private.

@pid_eins It's also supported behavior in "gdb" with "set inferior-tty" to reparent processes during debugging. Using systemd-run as a sudo replacement enables procrsses with same-pty elevation as an auth bypass, similarly when debugging is enabled on Linux (common) bypass is from any tty.

@pid_eins You do not need "tty" group to exploit this issue at all, just execution in the same user context that requested elevation via systemd.

@halfline I've no time to debate this with every person on the Internet further, I've shared what I consider to be the issue with two different methods of exploiting it that a new "sudo" which is "safe" and "secure" should take into account. Beyond that, am done giving free time to systemd

@halfline This isn't re-writing .bashrc or hijacking the user's execution environment, it is a child process obtaining elevated permissions when they do not have authorization for them (the vulnerability). Address the vulnerability, or don't, your choice.

@halfdebate @halfline "You've explained a vulnerability, but I am not going to acknowledge that vulnerability, because other vulnerabilities like keyloggers exist" - that's you. That's how you sound. Try, "thanks for sharing about this flaw, we should find ways to address it".

@halfline As an aside, the YAMA ptrace specifically was created to prevent risks between same-user debugging and was touted by systemd as being a protection here. I posted that wasn't the case and showed other ways. I don't appreciate my time being wasted further with this.

@halfline You also haven't even asked me how ptypwn.c works which is how I know you are disingenuous in our discussion - you just incorrectly assume that no boundary was being crossed yet it clearly shows a child process without controlling terminal taking over and using the root program.

@jspaleta @halfline Everything else can be found on my timeline including several lengthy discussions with ArchLinux security maintainer. The systemd project maintainer's only contribution to the discussion was insults and I really don't feel like giving more of my time away for free.

@Gabbymua4 There is also the matter of user confusion, a "sudo" replacement does not respect "sudoers" file or rights previously placed on sudo, instead it uses policy-kit enforcement which adds users by default to this new sudo without explict consent.

@apstrusus84 @two_d @artem_zin Some of the people commenting on these topics have been alive less time than you and I have been auditing and building systems, the fact that this new ethos is particularly prevalent amongst younger generations is telling. Systemd is an abomination, full of unnecessary bloat.

@two_d @apstrusus84 @artem_zin Oh sorry you wanted my prior work, here are 4 of them, though I used libc to target "su" in 2 of them - there's others I didn't release yet -



Feel free to read.
github.com/hackerhouse-op…
github.com/hackerhouse-op…
github.com/hackerhouse-op…
github.com/hackerhouse-op…
github.com/hackerhouse-op…

@two_d @apstrusus84 @artem_zin It's actually extremely interesting to me that a Microsoft developer is the one driving these changes in the Linux eco-system, considering the history lessons that could be learned looking at their own commercial design decisions here.