oss-sec mailing list archives
Re: s/party/hack like it's 1999
From: Solar Designer <solar () openwall com>
Date: Sun, 20 Sep 2015 06:26:31 +0300
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
Current thread:
- s/party/hack like it's 1999 up201407890 (Sep 17)
- Re: s/party/hack like it's 1999 Manuel Gómez (Sep 17)
- Re: s/party/hack like it's 1999 Solar Designer (Sep 19)
- Re: s/party/hack like it's 1999 Rich Felker (Sep 19)
- Re: s/party/hack like it's 1999 Solar Designer (Sep 19)
- Re: s/party/hack like it's 1999 David Holland (Sep 21)
- Re: s/party/hack like it's 1999 Greg KH (Sep 21)
- Re: s/party/hack like it's 1999 Florian Weimer (Sep 21)
- Re: s/party/hack like it's 1999 David Holland (Sep 26)
- Re: s/party/hack like it's 1999 Daniel Micay (Sep 26)
- Re: s/party/hack like it's 1999 Rich Felker (Sep 29)
- Re: s/party/hack like it's 1999 Solar Designer (Sep 19)
- Re: s/party/hack like it's 1999 Manuel Gómez (Sep 17)
- Re: s/party/hack like it's 1999 up201407890 (Sep 18)