[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150930044756.GA8645@brightrain.aerifal.cx>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
