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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ