Re: Terminal escape sequences - the new XSS for admins?

[Andy Lutomirski <luto () amacapital net>]

On 08/11/2015 01:29 PM, Steve Grubb wrote:
> On Tuesday, August 11, 2015 04:13:48 PM Daniel Kahn Gillmor wrote:
> > On Tue 2015-08-11 12:23:59 -0400, Kurt Seifried wrote:
> > > So we've had a bunch of this stuff over the years:
> > >
> > > http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=terminal+escape
> > >
> > > And now more recently:
> > >
> > > http://turbochaos.blogspot.ca/2014/08/journalctl-terminal-escape-injection
> > > .html https://bugzilla.redhat.com/show_bug.cgi?id=1084577
> > >
> > > And we have at least one more coming down the pipeline that's pretty
> > > widespread.
> > >
> > > Also I'm thinking of all those docker apps that log to STDOUT.
> > >
> > > So the basic TL;DR: please don't use really ancient terminal programs that
> > > are vulnerable to this stuff. It appears in testing that most (all?) of
> > > the
> > > Red Hat stuff is ok, but I can't speak for other vendors.
> >
> > Do we have a catalog of terminal programs that are vulnerable, or of
> > particularly dangerous escape sequences to test with each terminal
> > emulator?
>
> echo $'\e[30m'   - turns foreground black (used to trick people by hiding
> text)
> echo $'\e]2;ls -al\a' - set window title to 'ls -al'
> echo $'\e[21t' - print the window title to the command prompt. This is the one
> to watch out for.
>
> In my survey recently, Some emulators could set the window title; none of them
> supported reading the window title back to the command prompt. If you find one
> that does, it is one that is at risk.
>
> Also note that an attempt to foil or make it hard to set window titles is in
> bashrc under something called PROMPT_COMMAND. You may have to export
> PROMPT_COMMAND="" and then start a new shell to launch the terminal windows.
>
> In my survey over the weekend, I used Fedora 22 and tested the following:
>
> xterm - not vulnerable
> gnome-terminal - not vulnerable
> konsole - not vulnerable
> terminator - not vulnerable.
> qterminal - not vulnerable (Undecodable sequence: \001b(hex)[21t)
> Eterm - not vulnerable
> rxvt - not vulnerable
> st - not vulnerable (erresc: unknown csi ESC[21t)
> lilyterm - not vulnerable
> sakura - not vulnerable
> caja-terminal - not vulnerable
> xfce4-terminal - not vulnerable
> roxterm - not vulnerable
> mate-terminal - not vulnerable
> termit - not vulnerable
>
> A lot were based on the vte package. So, I dug into the vte package. In the
> file, vteseq.c, is this:
>
>                  case 21:
>                          /* Report a static window title, since the real
>                             window title should NEVER be reported, as it
>                             creates a security vulnerability.  See
>                             http://marc.info/?l=bugtraq&m=104612710031920&w=2
>                             and CVE-2003-0070. */
>                          _vte_debug_print(VTE_DEBUG_PARSE,
>                                          "Reporting fake window title.\n");
>                          /* never use terminal->window_title here! */
>                          g_snprintf (buf, sizeof (buf),
>                                      _VTE_CAP_OSC "lTerminal" _VTE_CAP_ST);
>                          vte_terminal_feed_child(terminal, buf, -1);
>                          break;
>
> At this point, I was convinced that most major emulators are safe. That
> said...there are all the ones I didn't check including older ones. The older
> ones are likely to be the ones I'd be most concerned about.

Are all the supposedly invulnerable terminals actually safe? 
Gnome-terminal reports:

0000000: 1b5d 6c54 6572 6d69 6e61 6c1b 5c       .]lTerminal.\

That's not as bad as echoing 'ls -al' back to the terminal input, but 
why is it considered acceptable for terminals to input anything 
whatsoever in response to the in-band data they receive?

--Andy