From: Stanislav Brabec <sbrabec@suse.cz>
To: up201407890@alunos.dcc.fc.up.pt
Cc: util-linux@vger.kernel.org
Subject: Re: Fixing su + runuser vulnerability CVE-2016-2779
Date: Thu, 3 Mar 2016 17:21:35 +0100 [thread overview]
Message-ID: <56D8648F.60504@suse.cz> (raw)
In-Reply-To: <20160303013722.22156xdxrqmywgw0@webmail.alunos.dcc.fc.up.pt>
On Mar 3, 2016 at 01:37 up201407890@alunos.dcc.fc.up.pt wrote:
> On another note, grsecurity recently released a new feature named
> GRKERNSEC_HARDEN_TTY that disallows the use of TIOCSTI to unprivileged
> users unless the caller has CAP_SYS_ADMIN.
This will fix all util-linux issues, but not chroot. There root inside
the chroot escapes from chroot and calls commands outside.
I can imagine yet another kernel level solution:
Implement a way to disallow TIOCSTI, eventually revoke terminal R/W access.
This would need application level fixes:
- Before calling the restricted process, disallow TIOCSTI.
- After returning from the restricted process, revoke terminal R/W.
> Brad Spengler (spender) said
> that looking into it, he didn't find legitimate uses of such ioctl, and
> no wide usage of writevt.
Some old systems had tiocsti(1) utility, probably used like a
predecessor of readline.
Just for curiosity, I just ran grep for TIOCSTI ioctl() over all
openSUSE sources. I got about 60 matches.
I analyzed use of some cases:
util-linux: used in agetty in wait_for_term_input()
kbd: contrib utility sti equal to tiocsti utility.
irda: Used by handle_scancode() to emulate input.
tcsh: Used in ed mode and in pushback().
emacs: Used in stuff_char() (putting char to be read from terminal)
...
It seems that TIOCSTI is used for:
- Read character, and if it does not match, put it back.
- Wait for character, than put it back for processing.
- Implementing a simple line editing.
--
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
next prev parent reply other threads:[~2016-03-03 16:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 19:35 Fixing su + runuser vulnerability CVE-2016-2779 Stanislav Brabec
2016-03-02 23:39 ` Ángel González
2016-03-03 0:37 ` up201407890
2016-03-03 16:21 ` Stanislav Brabec [this message]
2016-03-04 16:13 ` Stanislav Brabec
2016-03-04 18:03 ` up201407890
2016-03-04 23:50 ` Ángel González
2016-03-08 16:33 ` Stanislav Brabec
2016-03-07 13:13 ` Karel Zak
2016-03-08 16:02 ` Stanislav Brabec
2016-09-29 14:40 ` Karel Zak
2016-10-02 13:16 ` Florian Weimer
2016-10-03 10:28 ` Karel Zak
2016-10-03 13:29 ` Karel Zak
2016-10-09 11:09 ` Florian Weimer
2016-10-03 15:04 ` Karel Zak
2016-10-03 15:48 ` Pádraig Brady
2016-10-03 16:25 ` Karel Zak
2016-10-11 14:19 ` Karel Zak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56D8648F.60504@suse.cz \
--to=sbrabec@suse.cz \
--cc=up201407890@alunos.dcc.fc.up.pt \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.