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.