Date: Mon, 17 Aug 2015 23:27:48 +0300 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com 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: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202326 "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: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0955 "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: http://cve.mitre.org/cgi-bin/cvename.cgi?name=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: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0071 "The DEC UDK processing feature in the xterm terminal emulator in XFree86 18.104.22.168 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. Alexander
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.