LinuxQuestions.org - [SOLVED] [Slackware 14.1] su -c, tty hijacking, and some breakage

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - [Slackware 14.1] su -c, tty hijacking, and some breakage (https://www.linuxquestions.org/questions/slackware-14/%5Bslackware-14-1%5D-su-c-tty-hijacking-and-some-breakage-4175486942/)

[Slackware 14.1] su -c, tty hijacking, and some breakage

0. Background

It was discovered "su -c" (as implemented by shadow and coreutils) was vulnerable to tty hijacking (CVE-2005-4890). In particular, the threat was the potential for a non-privileged user to inject commands to a privileged tty.

Shadow 4.1.5+ addresses this by forking/setsid'ing in its PAM code. In the non-PAM code (which Slackware uses), this is addressed with a somewhat inelegant solution: detaching the controlling terminal via a TIOCNOTTY request.

1. Issue

Shadow's solution is omni-directional. In other words, "su -c" drops the controlling tty even when escalating privileges. This is rather unwarranted [1] because the threat vector of concern is injection from unprivileged->privileged.

There's a cost to shadow's fix since it renders a commonly-used method for executing commands as root (e.g. xterm -e /bin/su -s /bin/bash -c /bin/bash myscript) inoperable. See [2] and [3].

2. Proposal

There is an ongoing parallel effort by the shadow folks to develop a robust pty-based su (for both PAM and non-PAM cases). When mainlined, if it proves stable, it might be a good candidate for inclusion in Slackware's next version.

Meantime, for Slackware 14.1, I recommend the application of a patch I put together that makes "su -c" detach the controlling tty only if the callee is not root. This protects from unprivileged users injecting to privileged ttys while preserving old-style behavior when escalating privs:

shadow-4.1.5.1_CVE-2005-4890_relax.diff

Alternatively, the CVE fix could be reverted altogether making "su -c" always preserve the controlling tty as it did in shadow-4.1.4.3:

shadow-4.1.5.1_CVE-2005-4890_revert.diff

--mancha

-----
[1] http://seclists.org/oss-sec/2013/q2/374
[2] https://github.com/IgnorantGuru/spacefm/issues/394
[3] http://www.linuxquestions.org/questi...ks-4175462570/

I think I prefer the full revert, at least until they can fix it without breaking functionality.

Maybe the answer is to move to PAM? The non-pam stuff seems to be getting increasingly marginalised as time goes on, and PAM should have matured by now. Is there still any reason to avoid it?

I installed PAM as part of MSB package (in testing/) for screensaver to work (without it, it can't lock your desktop) and so far, everything worked out of the box without any problem

mancha that is an intresting problem.

I would say that the full revert is indeed the best solution here.

@willysr: I haven't had issues with pam either. 1 of the good things about pam these days is that you control what programs are using pam.
for example, for system logon with shadow it uses pam, but you dont want your ssh to use pam, than that is possible.

also it is interesting to see that pam seems to be more and more required by some things, like you said: screensaver *not only Mate has this issue, also (Dropline) Gnome)
ConsoleKit development has been stalled and since march 2012 nothing has been done.
The following has been written on the ConsoleKit website: http://www.freedesktop.org/wiki/Software/ConsoleKit/

Code:

ConsoleKit

ConsoleKit is a framework for defining and tracking users, login sessions, and seats.

    ConsoleKit is currently not actively maintained. The focus has shifted to the built-in seat/user/session management of Software/systemd called systemd-logind!

For this to work, pam is required.

Apart from ConsoleKit and systemd-logind, and dont know which other programs have these framework definitions.

As security has been a big issue over the last years, pam is a good candidate imo.

so for now full revert should be defiantly an option for PV.
and pam should be looked into

I expect difficult times coming for the Slackware team.
The upcoming 2-3 years we will see a lot of changes in distributions. (systemd/upstart) - (wayland/Xorg-server) - (linux kernel/non linux kernel)

Another example of breakage to add to the list: aszabo was unable to use gksu until he re-built shadow with either my relax or revert patch.

--mancha

Code:

Thu Feb 20 00:30:49 UTC 2014

patches/packages/shadow-4.1.5.1-i486-3_slack14.1.txz:  Rebuilt.

  Shadow 4.1.5 addressed a tty-hijacking vulnerability in "su -c"

  (CVE-2005-4890) by detaching the controlling terminal in the non-PAM

  case via a TIOCNOTTY request.  Bi-directional protection is excessive

  and breaks a commonly-used methods for privilege escalation on non-PAM

  systems (e.g. xterm -e /bin/su -s /bin/bash -c /bin/bash myscript).

  This update relaxes the restriction and only detaches the controlling

  tty when the callee is not root (which is, after all, the threat vector).

  Thanks to mancha for the patch (and the above information).

Looks like your modification hit patches/ - though I think I still prefer your full revert patch in this case as the risk can be avoided by user behaviour without sacrificing expected functionality.

Many slackers will be happy about this update; tagging as SOLVED.

--mancha

This should make one less known issues for MSB Project as well

Thanks :)

edit: nevermind, answer occurred to me. Forget I asked. ;)

@mancha: Nice job with the fix. Very happy indeed.