PoC to demonstrate root permission hijacking by exploiting “systemd-run”(twitter.com)
twitter.com
PoC to demonstrate root permission hijacking by exploiting “systemd-run”
https://twitter.com/hackerfantastic/status/1785495587514638559
8 comments
3rd example, its a pty permission problem as the OP said in his initial post and he suggested a tested fix. https://x.com/hackerfantastic/status/1786485377617846348
This is not a systemd-run specific issue either.
I reproduced this targeting sudo (just `cat` the parent tty), in fact able to capture my password as I type it in, and capture commands as they are being typed in. Surprised it was not mentioned that it breaks the terminal while you run it, no characters get sent to the program.
Edit: Here is a POC https://gist.github.com/bahorn/198987f55611f2011a91a5af09e7c... so you can see that this applies to sudo as well.
I reproduced this targeting sudo (just `cat` the parent tty), in fact able to capture my password as I type it in, and capture commands as they are being typed in. Surprised it was not mentioned that it breaks the terminal while you run it, no characters get sent to the program.
Edit: Here is a POC https://gist.github.com/bahorn/198987f55611f2011a91a5af09e7c... so you can see that this applies to sudo as well.
in the case of systemd the pty remains user owned once the root program is attached, this allows any user process to read and hijack the root program. sudo, su and doas ymmv. The suggested fix for systemd is to chown the slave pty to the user privilege that matches the attached program to prevent misuse.
I understand the issue, I have checked /dev/pts/ and seen systemd-run create a user readable pts there. I'm not adverse to that one getting chown()'d, but there really isn't any impact from it.
The problem is you can not hijack (meaning command exec right?) a root shell running under your account with this unless there is an approach that hasn't been mentioned yet. You can read character input, stopping the program from receiving input while you are doing so, of a process your user account directly started. I investigated the other ways and he hasn't given a viable one beyond running stuff directly in shell of the target session (TIOCSTI doesn't work if you target a different pty) or using ptrace.
All of these apply to other programs as even though they set root permissions on their pty as you can influence their parent. You need to chown both if you want to stop issues, but that'll probably break stuff. To be clear his whole point is that systemd is less secure compared to sudo etc but is using something that applies to everything to try and show that, involving using pocs that didn't even show the issues he was claiming, which is disingenuous.
The problem is you can not hijack (meaning command exec right?) a root shell running under your account with this unless there is an approach that hasn't been mentioned yet. You can read character input, stopping the program from receiving input while you are doing so, of a process your user account directly started. I investigated the other ways and he hasn't given a viable one beyond running stuff directly in shell of the target session (TIOCSTI doesn't work if you target a different pty) or using ptrace.
All of these apply to other programs as even though they set root permissions on their pty as you can influence their parent. You need to chown both if you want to stop issues, but that'll probably break stuff. To be clear his whole point is that systemd is less secure compared to sudo etc but is using something that applies to everything to try and show that, involving using pocs that didn't even show the issues he was claiming, which is disingenuous.
so fix the issue by chown the pty created by systemd and give the OP his dues for pointing the issue out, seems like unnecessary flaming beyond that as to why this can be used to freely hijack root permissions with ptrace_classic and tty ioctls is a wider problem that should also be addressed and protected against when elevating rights. Microsoft "sudo.exe" doesnt have the same issue and fixed an insecure pipe permission quickly that allowed it. As for the boundary policy kit auth for systemd-run is one-shot meaning users should be prompted for each elevation request but looks to be persistent for the lifetime of the elevated process as policy kit is no longer requesting auth when the user does any of the three methods OP outlined.
They have blocked me so I can't read their tweets.
Not shown: "systemd-run --shell" asks for the root password (or whatever set up for polkit authentication).
That some other process of the same user can influence that session with elevated privileges isn't really an issue. In fact, the terminal in which systemd-run was invoked is also owned by the user and can be "taken over" in the same way.
That some other process of the same user can influence that session with elevated privileges isn't really an issue. In fact, the terminal in which systemd-run was invoked is also owned by the user and can be "taken over" in the same way.
> The only thing this demonstrates is that the OP has just learned about how uid-based privilege boundaries work on Linux.
https://news.ycombinator.com/item?id=40229550
https://news.ycombinator.com/item?id=40229550
I have no idea (nor do I care) if this is serious or even real BUT the fact it will be turned into personal attacks on Poettering is just another reason why the entire Linux eco system stinks.
If this is real then great, it can be patched no need for attacks. If it's fake then shame on <whoever>, no need for attacks.
If this is real then great, it can be patched no need for attacks. If it's fake then shame on <whoever>, no need for attacks.
Alas as in most of humanity the stinky people are also vastly disproportionately squeaky too.
Personal theory, it's just really easy to feel better about yourself by being the true zealot who knows better, who sees ruin elsewhere. It's much harder to find empathy & appreciation, to see both good and bad mixing.
Personal theory, it's just really easy to feel better about yourself by being the true zealot who knows better, who sees ruin elsewhere. It's much harder to find empathy & appreciation, to see both good and bad mixing.
https://x.com/hackerfantastic/status/1786485377617846348
gives a 3rd example to explain the problem and suggests a fix. The pty should be chown() to root after a root program is attached.
gives a 3rd example to explain the problem and suggests a fix. The pty should be chown() to root after a root program is attached.
OP's advisory on this posted to github https://github.com/hackerhouse-opensource/exploits/blob/mast...
The only thing this demonstrates is that the author has no clue about how these things work on Linux. There is no real security boundary between different processes of the _SAME_ uid, especially when controlling the parent process. The exact same "hijacking" can be done to literally any other tool, including sudo. Or you can take over the X11 session and sniff passwords and whatnot. Or heck you can just append alias sudo='mykeylogger sudo' into bashrc and go to the pub instead of having to wait for the right process to start at the right time. If you have write and execute privilege of a user, anything that user does can be compromised.
The reality is that this is just self-promotion from a grifter, and that's why it's happening on Twitter. If it was a real issue from a competent researcher it would have been reported via the appropriate channels, not on social media to feed haters and trigger the usual abuse and death threats while chasing impressions.
The reality is that this is just self-promotion from a grifter, and that's why it's happening on Twitter. If it was a real issue from a competent researcher it would have been reported via the appropriate channels, not on social media to feed haters and trigger the usual abuse and death threats while chasing impressions.
the op was sent harassing messages and insults by the package maintainer, who are you to demand how and where people discuss security issues? the write up on github is very detailed and identifies a vulnerability added by systemd that can be fixed. Systemd claiming its a victim of abuse and death threats is laughable when they instigated attacks on the OP and his credibility. Calling security researchers grifters for sharing their work is ultimately harmful to users.
No, the OP was not sent any harassment, the OP _did_ the harassment as it can be seen in the tweets. I mean, they are right there, just click on the links you shared. One of the OP's followers even openly called for the assassination of the project maintainer, and you have the galls to defend him? This is truly deranged stuff.
And again, there is no "vulnerability", there is simply a person that doesn't know how Linux works and has learned something new. Which again it's fine, nobody knows everything and we all learn new things everyday, it's just that normal and sensible people don't use that to make grand claims on social media and start harassment campaigns culminating in death threats.
Professional security researchers responsibly report real issues using the appropriate channels, such as defined at: https://github.com/systemd/systemd/security/policy this is not the work of a researcher, this is a grifter looking for self-promotion on social media.
And again, there is no "vulnerability", there is simply a person that doesn't know how Linux works and has learned something new. Which again it's fine, nobody knows everything and we all learn new things everyday, it's just that normal and sensible people don't use that to make grand claims on social media and start harassment campaigns culminating in death threats.
Professional security researchers responsibly report real issues using the appropriate channels, such as defined at: https://github.com/systemd/systemd/security/policy this is not the work of a researcher, this is a grifter looking for self-promotion on social media.
You're just making stuff up here, the OP was sent abuse firstly by pottering and handled the situation quite professionally by providing a detailed overview of the issue he posted and responding to the maintainers deflections with further information. The OP sent no death threats and posted about his perspectives and technical data on what he sees as a medium risk issue in systemd's pty handling. Why not chown the pty as he suggests, reduce the risk and thank him for giving his time freely on this matter? Conflating the behavior of others against Pottering as somehow someone discussing systemd publicly being responsible is classic DARVO actions. The OP was attacked by pottering, not the other way around.
Matthew was shitting on systemd and pulling no shots. Poettering calling Matthew a scriptkiddie is mild.
He did call me a "facist weenie" with no clear reason why beyond me pushing back on their grand claims.
He did call me a "facist weenie" with no clear reason why beyond me pushing back on their grand claims.
At this point GNU/Linux will be as secure as running GNU stuff under ITS.
It could be more convenient for pure hacking, tho.
The other demonstration shows the latter part, but requires you to have a reverse shell in the parent and can't be abused across users.
https://twitter.com/hackerfantastic/status/17860809689581612...
Generally, this issue is overblown. Both of these "exploits" works on `su`, `sudo` and probably `doas` because of session caching or because you have access to `ptrace`.
I'm not sure what security boundary you are breaking and this seems more like a cheap dig at `systemd` to feed into the decade-old hate train at this point.