Stack Clashing is pretty neat, something you should really pay attention to in embedded spaces (its often exploitable in UEFI land as most EDK2 builds lack guard pages).
I got to write some exploits for some recently, very fun bug class to exploit.
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.
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.
I put a bit further thought into this. The claim is that because the pty has user permissions its possible to hijack it, but that really hasn't been true for years which is why the two PoC do things like use reptyr (involves replacing fd's with ptrace [1], needing either a parent relationship or capabilities that aren't default) or running a command like netcat directly from the pty you want to control [2] (essentially ttyjack [3]).
If you look at the implementation of TIOCSTI [4], 99% sure this is what the new PoC is doing, you can see why you can't do this across ttys.
This goes back ages, even into some 2.6 kernels it seems before I got bored going back kernel versions.
I went and tested all this on a Ubuntu 22.04 box, not possible unless there is a new trick to hijack ttys. I tried the TIOCLINUX across ttys physically at the machine and that didn't work either.
This is not a real bug and the trick is possible with sudo if you just hijack the parent process of sudo with reptyr instead of sudo directly.
Also seems a bit absurd to try and pretend there is a security boundary between processes started by the same user. You could already do PATH trickery here, a time honoured tradition.
From their FAQ and blog posts, I don't believe they apply much FHE. Seems what they do is use work from a different subfield [1], which seems to be able to achieve the required speeds and still be able to work with more complex queries.
Techniques I'm seeing in the Pappas et al. paper mentioned in the history section of [1] to do more complex queries seems pretty cool, and I imagine the performance has been improved a bit in more recent work.
I got to write some exploits for some recently, very fun bug class to exploit.