Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 20 Sep 2015 06:26:31 +0300
From: Solar Designer <>
Subject: Re: s/party/hack like it's 1999

Thank you for posting this, Rich!

On Sat, Sep 19, 2015 at 10:28:11PM -0400, Rich Felker wrote:
> Writer 1: C2 A9
> Writer 2: C3 9B 31 6D
> One possible interleaving (writes to terminals have _no_ atomicity at
> all) is:
> C3 C2 9B 31 6D A9
> This of course contails illegal sequences. The standard practice for
> processing the above sequence of bytes is to drop or replace truncated
> or illegal sequences. The exact manner in which this is done varies,
> but since most software tries to minimize data loss in the case of
> dropped or corrupt bytes, the usual interpretation is:
> [illegal C3] [valid C2 9B] [valid 31] [valid 6D] [illegal A9]

And in case a terminal assumes the next byte after C3 is corrupt rather
than lost, so would treat [illegal C3 C2] for the example above, this
can still be bypassed with a third writer happening to insert any byte
after the C3, so we'd have e.g.:

Writer 1: C2 A9
Writer 2: C3 9B 31 6D
Writer 3: 41

and the attacker's desired interleaving would be:

C3 41 C2 9B 31 6D A9


[illegal C3 41] [valid C2 9B] [valid 31] [valid 6D] [illegal A9]

> Regardless of how the illegal sequences are dropped/replaced, then,
> the characters in the middle are:
> U+009B U+0031 U+006D
> or:
> CSI '1' 'm'
> If C1 characters are processed, that put your terminal in bold mode.
> Note that all that was needed for this to happen was for a stray C2
> byte from one writer to get injected just before the character-final
> 9B byte of a multibyte character from another writer. I specifically
> chose my example so that both writers output data which is well-formed
> and printable UTF-8, but that was not necessary.
> Since I see no reasonable application-side mitigation for this, I

Yeah.  A user's mitigation may be to avoid running multiple programs at
a time on a UTF-8 terminal.  E.g. running "ps &" appears unsafe
(although is indeed unlikely to actually be used in a successful
attack), even if "ps" replaces control characters with question marks.

> think the right recommendation should be disabling C1 control codes in
> terminal emulators, at least in UTF-8 mode, but preferably just across
> the board. AFAIK nothing is using them. They don't even work reliably
> across all terminal emulators; many users have C1 disabled from the
> old days where that was the right way to use certain legacy 8-bit
> encodings, and some UTF-8 terminal emulators probably don't even
> support them at all.

I still have:

XTerm*allowC1Printable: true
XTerm*allowFontOps: false
XTerm*allowTcapOps: false
XTerm*allowTitleOps: false
XTerm*allowSendEvents: false
XTerm*allowWindowOps: false

Non-security, but also useful (if anyone is still using classic xterm):

XTerm*saveLines: 10000

> Note that when considering disabling C1 controls in screen or tmux,
> it's important that the attaching terminal also has them disabled.
> Otherwise screen/tmux will treat them as printable and pass them
> through to be interpreted by the attaching terminal, which is
> potentially even more dangerous. It would be nice to see an option in
> screen/tmux not to treat C1 as printable but rather filter out these
> characters, so that users running everything in screen/tmux don't have
> to worry about potentially dangerous settings on the terminal they
> attach from.

I agree.


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ