3 ms·
Ah, this looks like the old ungetc() exploit, where (back in the 1980s at utexas.edu) we'd leave a process connected to a terminal, wait for another user to log
by erlkonig 8y ago
Ah, this looks like the old ungetc() exploit, where (back in the 1980s at utexas.edu) we'd leave a process connected to a terminal, wait for another user to log in, then push characters to their shell from our program using ungetc(). Essentially, each character pushed ends up looking like a fresh input character to the other program. The basic issue is whether all open file handles that shouldn't be there (our hack program, for example) got closed out by the new login session. For something like login, the question is easy, ONLY itself should be connected early on. For su, it's much weirder, since the user may have created background jobs before running su, and su and sudo can't reasonably close all other handles on the original tty device.
Further su and sudo can't close all file descriptors of the "sub-session" as it exits, because that the "sub-session" is created by forking, so su/sudo aren't around at the end.
Creating a separate pseudo-terminal device to allow for draconian cleanup, and prevent even having both user IDs connected to the same tty device, seems like the best place to start.
Hmm, now I want to go update the user-group-setter program I use (which also can set auth user IDs on Solaris, etc) and try having it do ptty allocation for the subjob.
In the meantime, try this to get a session and run through the same demo steps:
setsid -w su - <user>
Won't for everything (no /dev/tty), but it does block the example. You can add a tty if you have one handy, too, by using redirection in the spawned process in this general form, but I don't currently have the cluon for how to create a /dev/pts/<num> from the shell level - if someone can construct the full command, I'd like to see it :-)
setsid sh -c 'exec command <> /dev/tty2 >&0 2>&1'
- jwilk 8y ago> I don't currently have the cluon for how to create a /dev/pts/<num> from the shell level As I recommended in http://www.openwall.com/lists/oss-security/2018/06/14/2 http://www.openwall.com/lists/oss-security/2018/06/14/2 , use screen or tmux: screen su - <user> script(1) is more lightweight than screen/tmux, but it can't be easily persuaded to run arbitrary commands, such as "su". :-/
- JdeBP 8y ago> su/sudo aren't around at the end. Yes, they are. The world has changed since the 1980s. This particular aspect changed in the middle 1990s. * http://jdebp.eu./FGA/dont-abuse-su-for-dropping-privileges.html http://jdebp.eu./FGA/dont-abuse-su-for-dropping-privileges.h... There are plenty of tools for manipulating pseudo-terminals, but the correct solution here, that people have been pressing for for quite a number of years now and that some kernel people have already implemented, is to simply remove this ioctl() entirely. setsid() is incorrect for the reasons that Karel Zak alluded to in June 2017, and the work to patch the few users of TIOCSTI such as the C shell and mail has already been done by the OpenBSD people. * https://news.ycombinator.com/item?id=17312775 https://news.ycombinator.com/item?id=17312775 * http://jdebp.eu./Softwares/nosh/guide/commands.html#ChainLoading http://jdebp.eu./Softwares/nosh/guide/commands.html#ChainLoa... * http://jdebp.eu./Softwares/djbwares/ http://jdebp.eu./Softwares/djbwares/