Date: Wed, 30 Sep 2015 00:47:56 -0400 From: Rich Felker <dalias@...c.org> To: oss-security@...ts.openwall.com Subject: Re: s/party/hack like it's 1999 On Sat, Sep 26, 2015 at 10:26:09PM +0000, David Holland wrote: > On Mon, Sep 21, 2015 at 09:02:27PM +0200, Florian Weimer wrote: > > >> I have been arguing for years (but without success) that vt bomb > > >> injection needs to be blocked in the tty driver. This problem > > >> (corruption of concurrent UTF-8 streams) needs to be too, as a matter > > >> of correctness and not even security. > > > > > > How exactly would a tty driver "block" anything like this? > > > > Avoiding in-band signaling in the first place. :-/ > > Yes, that. > > > > A tty driver never looks at the data stream in the kernel, as that > > > way lies madness... > > > > Surely there is a way to prevent two writes from interleaving? For > > writes to files in O_APPEND mode, this already happens, doesn't it? > > Theoretically each write() call is supposed to be atomic; there are This is only true for regular files and for pipes when the size is bounded by PIPE_BUF. > presumably some limits to that in practice, especially on ptys (like > PIPE_BUF is the limit for pipes) but this doesn't help if programs > emit partial characters, as is (in general) likely. Programs that use > stdio to write to stdout are ok because stdio line-buffers stdout when > it's a tty; but that doesn't help with stderr, or with programs that It also does not help for lines longer than the stdio buffer size. > ship text around in arbitrary-sized blocks, or programs in cbreak > mode, or if you're logged in across a network that hiccups > occasionally. (Or can be made to hiccup on purpose.) > > ISTM that for safety the tty driver is going to have to know about > multibyte encodings and not let through partial characters; this is an > enormous can of worms. This is not possible. Ttys are not terminals and do not deal in text. They are bidirectional byte-granularity IO devices. (Yes there's canonical mode which has some text interpretation but that's only at the endpoints and not always in use; it's not part of the actual data channel.) > (but, let's not overreact; it's always been possible to blat out > sequences beginning with [ and hope that they'll be inserted right > after someone else's ESC.) Well that's not going to happen if none of the writers are writing non-printable characters (ESC is non-printable). What's unique about the UTF-8 interleaving is that you can interleave _printable_ characters and get a control character. But in general I agree that we should not be over-reacting. I think the simple, clean, non-invasive solution that won't break any real-world apps is just deprecating C1 controls once and for all -- set them off by default in existing terminals that used to have them on by default, and don't implement them at all in new terminals. Rich
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ