[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170603165813.GA20708@openwall.com>
Date: Sat, 3 Jun 2017 18:58:13 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Karel Zak <kzak@...hat.com>
Subject: TIOCSTI not going away
Hi,
Many su-like programs can be used to run other programs with reduced (or
otherwise different, rather than strictly elevated) privileges. This
includes su itself (such as when su'ing from root to a user), as well as
various container entry commands, etc.
Many (probably most) of those got it wrong at first, keeping the same
tty across the privilege boundary. Numerous such issues were reported:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tiocsti
http://www.openwall.com/lists/oss-security/2011/06/02/3
http://www.openwall.com/lists/oss-security/2012/11/05/8
http://www.openwall.com/lists/oss-security/2016/02/25/6
http://www.openwall.com/lists/oss-security/2016/02/27/1
http://www.openwall.com/lists/oss-security/2016/09/25/1
This list is not exhaustive.
Some programs got it right IIRC as of the first time I looked (maybe
right from the start): SimplePAMApps su, vzctl.
On LKML, CC'ed to the kernel-hardening mailing list, Matt Brown has been
pushing for the upstream Linux kernel to introduce an option (likely to
be disabled by default) that would block the TIOCSTI ioctl. Alan Cox
repeatedly NAK'ed this:
http://www.openwall.com/lists/kernel-hardening/2017/05/
Sorry there's no one specific message/thread to link to - there were
multiple patch revisions, and multiple NAKs with different wording.
Alan's reasoning is that userspace apps like this have to be allocating
a new pty anyway, and the kernel change wouldn't help much since TIOCSTI
isn't the only way to cause trouble (although per my reading of the
examples given, other ways/troubles are either not exactly as bad or not
exactly as generic). Alan also suggested that all of the affected
userspace apps have already been fixed. I think that's still very far
from true. In fact, just 2 days ago util-linux 2.30 was released with
the issue still deliberately not fixed:
https://marc.info/?l=util-linux-ng&m=149640144016887
| CVE-2016-2779 - This security issue is NOT FIXED yet. It is possible to
| disable the ioctl TIOCSTI by setsid() only. Unfortunately, setsid()
| has well-defined use cases in su(1) and runuser(1) and any changes
| would introduce regressions. It seems we need a better way -- ideally
| another ioctl to disable TIOCSTI without setsid() or in a userspace
| implemented pty container (planned as experimental su(1) feature).
I am posting this message primarily to let maintainers of userspace
su-like programs know that they should in fact proceed to implement
allocation of a separate pty, if they don't do that already. Do not
wait for the kernel to do some magic thing because it's been NAK'ed, it
wouldn't fully address the issue, and it wouldn't be enabled by default.
Another point Alan brought up is that if a program is careless enough
not to allocate a new pty, it's probably also careless enough not to
close any fd's that might be open in the parent shell or by the program
itself. Let's also not miss this reminder and review/correct/harden
these same programs in this respect as well.
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
