Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 3 May 2017 01:36:03 +0200
From: Solar Designer <>
Subject: Re: terminal emulators' processing of escape sequences

On Mon, May 01, 2017 at 06:44:28PM +0200, Solar Designer wrote:
> It is a well-known feature, previously discussed in here, that data
> printed to a terminal (emulator) may control that terminal, including
> making it effectively unusable until reset, and in some cases even
> pasting characters as if they were typed by the user.  Also as discussed
> what characters may be pasted varies by terminal - sometimes they can be
> arbitrary (e.g., if the terminal supports macro recording and playback
> via escape sequences) and sometimes not so (like a terminal reporting
> back its status, usually not followed by a linefeed, so not yet
> executing a shell command until further user assistance).  Here are some
> relevant threads:
> (I link to messages that started these threads, not necessarily to most
> informative messages in the threads.  So you might want to go through
> the threads with the "thread-next" links.)

Adding to the above older sub-topic of (mis)features rather than bugs,
here's a particularly relevant one, quoting excerpts from:

| Operating System Commands
| OSC Ps ; Pt BEL
| OSC Ps ; Pt ST
|             Ps = 5 2  -> Manipulate Selection Data.  These controls may
|           be disabled using the allowWindowOps resource.  The parameter
|           Pt is parsed as
|                Pc; Pd
|           The first, Pc, may contain zero or more characters from the
|           set c  p  s  0  1  2  3  4  5  6  7 .  It is used to construct
|           a list of selection parameters for clipboard, primary, select,
|           or cut buffers 0 through 7 respectively, in the order given.
|           If the parameter is empty, xterm uses s 0 , to specify the
|           configurable primary/clipboard selection and cut buffer 0.
|           The second parameter, Pd, gives the selection data.  Normally
|           this is a string encoded in base64.  The data becomes the new
|           selection, which is then available for pasting by other appli-
|           cations.
|           If the second parameter is a ? , xterm replies to the host
|           with the selection data encoded using the same protocol.
|           If the second parameter is neither a base64 string nor ? ,
|           then the selection is cleared.

The potential for use in attacks is mitigated by the fact that the reply
triggered by setting the second parameter to ? is "encoded using the
same protocol", so its string portion is in base64 and thus in its
encoded form won't contain a linefeed.  However, altering X clipboard's
content is nevertheless nasty and perhaps unexpected by a user.  If the
user pastes the clipboard into a terminal, perhaps thinking there's
still an intended command they had saved in there before, the replaced
content's embedded linefeed(s) will be pasted as such, thereby
immediately executing the attacker's command(s).

The feature is in fact present and working in xterm when allowWindowOps
is enabled (even though the clipboard isn't specific to one "window"),
and is non-working when it's disabled.  (I've just tested.)

[user@...t ~]$ echo -e '\x1b]52;;dGVzdAo=\x1b\\'

[user@...t ~]$ echo -e '\x1b]52;;?\x1b\\'

^[]52;s0;dGVzdAo=^[\[user@...t ~]$ 52;s0;dGVzdAo=

Per a quick search, it appears to also be present in mintty:

and iTerm2:

and perhaps elsewhere.


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.