Message-ID: <CANA3KFWE2kUwdzGAGwRn8x4ceFzx5Z-quC2WBwqvks8LkTCh+A@mail.gmail.com>
Date:   Wed, 31 May 2017 21:27:49 +1000
From:   Peter Dolding <oiaohm@...il.com>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     "Serge E. Hallyn" <serge@...lyn.com>,
        Kees Cook <keescook@...omium.org>,
        Daniel Micay <danielmicay@...il.com>,
        Matt Brown <matt@...tt.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jann Horn <jannh@...gle.com>, James Morris <jmorris@...ei.org>,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI
 ioctl require CAP_SYS_ADMIN

On Wed, May 31, 2017 at 7:52 AM, Alan Cox <gnomes@...rguk.ukuu.org.uk> wrote:
>> > So tty stuff should under a tty capabilities.
>>
>> (last reply on this)
>>
>> Currently capabilities.7 says
>>
>>               * employ  the  TIOCSTI ioctl(2) to insert characters into the input queue of a
>>                 terminal other than the caller's controlling terminal;
>>
>> for CAP_SYS_ADMIN.
>>
>> So you can create a new CAP_SYS_TIOCSSTI if you like, and offer a patch where
>> *both* CAP_SYS_ADMIN and CAP_SYS_ADMIN suffice.  Again, see CAP_SYSLOG for a
>> prior example.
>
> Even then it wouldn't be useful because the attacker can use every other
> interface in the tty layer, many of which you can't magic away behind a
> capability bit. And the applications would need changing to use the
> feature - at which point any theoretical broken apps can instead be fixed
> to use a pty/tty pair and actually fix the real problem.
>
Alan is right.   CAP_SYS_ADMIN allows crossing the tty barrier.

Broken applications that you can wrap in a pty/tty pair as the lxc
application does would be defeated if those applications move up to
CAP_SYS_ADMIN.  Because you have granted the high right of cross
pty/tty containment.

Pushing CAP_SYS_TIOSSTI out by itself without the feature in
CAP_SYS_ADMIN means broken applications can be allowed to run in like
a lxc container where they cannot go anywhere with the exploit because
the pty/tty they are picking is not going to get them very far at all.

Pushing TIOSSTI up to CAP_SYS_ADMIN to address this problem is wrong.
 Question is also how many applications use CAP_SYS_ADMIN feature to
push chars into other pty/tty on the system.   Pushing across pty/tty
barrier may not be a suitable feature to be generically in
CAP_SYS_ADMIN in the first place.

http://www.halfdog.net/Security/2012/TtyPushbackPrivilegeEscalation/

This here is example of TIOSSTI pushback as CAP_SYS_ADMIN being bad.
I don't know of a genuine program using push back in exploiting way
where the pushed back input is expected to be processed after the
program has terminated.

Really we need to work out how many breakage will in fact be caused by
majority restricting both pushback and write across tty barrier.
This is not like CAP_SYS_LOG these are features that can be used to
exploit system badly.   It is possible that the exploiting form of
TIOSSTI pushback is used by nothing genuine userspace in any properly
functional case.   So if that is the case unconstrained TIOSSTI
push-back would only be making application crashes worse.

The reason I want TIOSSTI pushback moved to its own CAP_SYS first is
to find out if anything is in fact using it as part of genuine usage
and allowing anyone caught out to work around it.    I am sorry this
is me most likely using X11 logic break it and see if anyone yells.
If no one complains disappear the feature completely then this closes
this form of exploit for good.

Peter Dolding

Powered by blists - more mailing lists