lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230625155625.s4kvy7m2vw74ow4i@begin>
Date:   Sun, 25 Jun 2023 17:56:25 +0200
From:   Samuel Thibault <samuel.thibault@...ilenet.fr>
To:     Kees Cook <kees@...nel.org>, Kees Cook <keescook@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Simon Brand <simon.brand@...tadigitale.de>,
        linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org,
        Dave@...lke.cc
Subject: Re: [PATCH v3 2/2] tty: Allow TIOCSTI to be disabled

Hello,

Samuel Thibault, le mer. 28 déc. 2022 21:57:26 +0100, a ecrit:
> Kees Cook, le mar. 27 déc. 2022 19:32:55 -0800, a ecrit:
> > On December 27, 2022 3:40:00 PM PST, Samuel Thibault <samuel.thibault@...ilenet.fr> wrote:
> > >Kees Cook, le sam. 22 oct. 2022 11:29:49 -0700, a ecrit:
> > >> TIOCSTI continues its long history of being used in privilege escalation
> > >> attacks[1]. Prior attempts to provide a mechanism to disable this have
> > >> devolved into discussions around creating full-blown LSMs to provide
> > >> arbitrary ioctl filtering, which is hugely over-engineered -- only
> > >> TIOCSTI is being used this way. 3 years ago OpenBSD entirely removed
> > >> TIOCSTI[2], Android has had it filtered for longer[3], and the tools that
> > >> had historically used TIOCSTI either do not need it, are not commonly
> > >> built with it, or have had its use removed.
> > >
> > >No. The Brltty screen reader entirely relies on TIOCSTI to be able to
> > >support input from various Braille devices. Please make sure to keep
> > >TIOCSTI enabled by default, otherwise some people would just completely
> > >lose their usual way of simply typing on Linux.
> > 
> > Yup, it remains default enabled:
> 
> Yes, but thining of it, very soon people in various security-sensitive
> distributions will disable it, as they should indeed. And people who
> need to use their Braille device on such distributions will get stuck.

And as expected, it did get disabled in Debian for instance, very much
to the dismay of blind users, whose keyboard suddenly stopped working at
all after rebooting with a Linux 6.3 kernel!...

> Can we perhaps just introduce a CAP_TIOCSTI that the brltty daemon would
> be able to use? We could even make it only allow TIOCSTI on the linux
> console (tty->ops == con_ops).

*Please* comment on this so we can progress. ATM people are
advising each other to set dev.tty.legacy_tiocsti=1, which is just
counter-productive in terms of security...

Really, this a serious regression for the people affected by this.

Samuel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ