[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55CA6BBC.7070101@amacapital.net>
Date: Tue, 11 Aug 2015 14:40:12 -0700
From: Andy Lutomirski <luto@...capital.net>
To: oss security list <oss-security@...ts.openwall.com>
Cc: Daniel Kahn Gillmor <dkg@...thhorseman.net>,
Kurt Seifried <kseifried@...hat.com>
Subject: Re: Terminal escape sequences - the new XSS for admins?
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
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.
