Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 17 Aug 2015 23:27:48 +0300
From: Solar Designer <>
Subject: Re: Terminal escape sequences - the new XSS for admins?

On Mon, Aug 17, 2015 at 12:38:34PM -0700, Michal Zalewski wrote:
> Another nice tidbit:

"To reproduce:
1. switch to console
2. cat teken-*
-> kernel panic"

Yes, let's not forget that even with "safe" terminal emulators (in terms
of what escapes they support), having other programs expose them to
arbitrary data (including any escape characters) increases the attack
surface, as compared to also having the escapes filtered by those other
programs like some have been doing so far (e.g., syslogd).

For example, XFree86 had a buffer overflow via window title:

"Buffer overflow in fbglyph.c in XFree86 before 4.2.0, related to glyph
clipping for large origins, allows attackers to cause a denial of
service and possibly gain privileges via a large number of characters,
possibly through the web page search form of KDE Konqueror or from an
xterm command with a long title."

Even if a "safe" terminal emulator lacks an escape sequence to paste the
window title onto the command line, it can still be used to exploit
relevant vulnerabilities in the underlying libraries and X server... as
well as in its own code, if there are any.

Also, besides CVE-2003-0063:

"The xterm terminal emulator in XFree86 4.2.0 and earlier allows
attackers to modify the window title via a certain character escape
sequence and then insert it back to the command line in the user's
terminal, e.g. when the user views a file containing the malicious
sequence, which could allow the attacker to execute arbitrary commands."

there was:

"The DEC UDK processing feature in the xterm terminal emulator in
XFree86 and earlier allows attackers to cause a denial of
service via a certain character escape sequence that causes the terminal
to enter a tight loop."

which once again highlights the risk of bugs in processing of terminal
escapes, beyond whatever dangerous features there might (not) exist.

These bugs are old (unlike Michal's FreeBSD bug reference, which is a
freshly discovered bug), but there's no reason not to expect more bugs
of this kind.

This is why I am not happy about this thread's apparent decision to
dismiss unsafe handling of likely terminal escapes (the known ranges) in
untrusted input in individual programs as long as there are no known
worse-than-DoS intentional features in modern terminal emulators.
I would be happier to have this layer of security as well.  Besides, DoS
issues are a concern too, and are obviously available as intentional
features in typical terminal emulators.


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.