[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150920032631.GA2301@openwall.com>
Date: Sun, 20 Sep 2015 06:26:31 +0300
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
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
So:
[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.
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.
