A recent use-case on Slackware made me re-visit CVE-2005-4890
in the context of "su -c". Particularly, shadow's implementation
as of shadow 4.1.5.
During the discussions of this CVE (see footer links), it was
pointed out shadow's fix is partial given interactive su remains
vulnerable to tty-hijacking. It was also mentioned this vector
is less worrisome given use cases for interactive su are primarily
privilege escalation.
The CVE was always a bit controversial with many believing
using su and sudo to drop privileges is unsafe and more an
administration issue than a design flaw.
All that said, at the very least would it be reasonable to
apply the same threat-assessment criterion to the crippling
of "su -c" and not drop the controlling tty for the case when
the callee is root?
Slackware doesn't use PAM so the fix in shadow relies on a
TIOCNOTTY ioctl() request and not a setsid() call. One result
of this change is summarized in the table below:
shadow
4.1.4.3 4.1.5.1 4.1.5.1+patch*
1. As unpriv user user1:
xterm -e su -c $COMM SUCCESS FAIL SUCCESS
xterm -e su user2 -c $COMM SUCCESS FAIL FAIL
2. As root:
xterm -e su user1 -c $COMM SUCCESS FAIL FAIL
-----
* See attached
Cheers.
--mancha