XSS Vulnerability - Githubissues

Hello there from your friendly HTML5 terminal (Gate One) neighbor! I was playing around with graphterm today and noticed that there's a cross-site scripting (XSS) vulnerability in lineterm.py that has to do with the way it falls back when the escape sequence does not include the a valid cookie...

# ~line 2518:
content = lxml.html.fromstring(content).text_content()

This will automatically take care of things like <script>alert("pwned!")</script> but it actually does the opposite if the HTML is already escaped. Example (run in python interpreter):

open('/tmp/malicious.txt', 'w').write("\x1b[?1155;1h<!--gterm pagelet current_dir=/tmp-->&lt;script&gt;alert('You just got pwnd!');&lt;/script&gt;\x1b[?1155l")

If you execute the line above and cat /tmp/malicious.txt inside a graphterm terminal you'll get that alert box... Demonstrating the vulnerability.

Obviously '1' (in the escape sequence '\x1b[?1155;1h') is not a valid graphterm cookie but this attack will still work because lxml.html.fromstring(content) will unescape HTML entities when you call text_content().

The (best) fix for this is to perform HTML escaping (for invalid cookies) as the last step before the output is written to the terminal. Please feel free to include/use the strip_xss() function from my htmltag module. It will automatically take care of all known XSS vulnerabilities.

In Gate One's HTML output plugin I did not allow script execution at all because I was worried about things like 'wall' and 'write user' in addition to issues that can crop up with shared terminals (more a problem with broadcasts than "shared with coworker/friend" situations). I can also envision attacks where the user's .profile gets modified allowing the attacker to not only 'own' the user on the server in question but also the browser that's running on their desktop.

Dan, Thanks for the tip. Luckily (or unluckily!) GraphTerm does not have many users yet! I'll fix it soon. As you would may recognize, the original lineterm code is derived from AjaxTerm. I actually did play with your EFTW at some point.

I have been slowly improving HTML security, to avoid XSRF attacks etc. It is a long road...

Perhaps we'll meet at some point to discuss HTML5 terminals.

Regards, Saravanan

On Wed, Jun 26, 2013 at 12:42 PM, Dan McDougall notifications@github.comwrote:

Hello there from your friendly HTML5 terminal (Gate One) neighbor! I was playing around with graphterm today and noticed that there's a cross-site scripting (XSS) vulnerability in lineterm.py that has to do with the way it falls back when the escape sequence does not include the a valid cookie...

~line 2518:

content = lxml.html.fromstring(content).text_content()

This will automatically take care of things like
but it actually does the opposite if the HTML is already escaped. Example (run in python interpreter): open('/tmp/malicious.txt', 'w').write("\x1b[?1155;1h<script>alert('You just got pwnd!');</script>\x1b[?1155l") If you execute the line above and cat /tmp/malicious.txt inside a graphterm terminal you'll get that alert box... Demonstrating the vulnerability. Obviously '1' (in the escape sequence '\x1b[?1155;1h') is not a valid graphterm cookie but this attack will still work because lxml.html.fromstring(content) will _unescape_ HTML entities when you call text_content(). The (best) fix for this is to perform HTML escaping (for invalid cookies) as the last step before the output is written to the terminal. Please feel free to include/use the strip_xss() function from my htmltaghttps://github.com/LiftoffSoftware/htmltag/blob/master/htmltag.py#L186module. It will automatically take care of all known XSS vulnerabilities. In Gate One's HTML output plugin I did not allow script execution at all because I was worried about things like 'wall' and 'write user' in addition to issues that can crop up with shared terminals (more a problem with broadcasts than "shared with coworker/friend" situations). I can also envision attacks where the user's .profile gets modified allowing the attacker to not only 'own' the user on the server in question but also the browser that's running on their desktop. — Reply to this email directly or view it on GitHubhttps://github.com/mitotic/graphterm/issues/5 .

Fixed using cgi.escape(lxml.html.fromstring(content).text_content()) in release 0.40.1 (Strangely enough, the bug only shows up on my Mac. It doesn't seem to affect Ubuntu 12.04.) Thanks again for finding this vulnerability.

As for the larger issue of script execution, the current GraphTerm security model is that if a program has access to the cookie stored in an environment variable, it can execute just about anything locally or in the browser. (It is true that one needs to be careful with broadcasts to ensure that any information coming back from the read-only browser display to the GraphTerm server is carefully sanitized.)

That fix sounds like it will resolve the problem just fine. Closing ticket.

BTW: We should definitely talk about web-based terminals as I'd love to come up with standards for all sorts of things. Especially in regards to HTML output and means of providing metadata along with text. In your 'gls' program you examine each file in the listing and provide HTML output which is a good start but I'd rather come up with a standard that we can add to the GNU toolset itself (ls, df, etc).

Having standards would also enable other applications to provide metadata along with their textual output. For example, it would be great if 'top' output the full line's worth of information for any given process as metadata so the user could mouse over it to get a more complete view of a process.

Ideally it would be nice and generic with arbitrary specifiers (aka metadata types) to make it infinitely expandable. It should also not show up on terminals that do not support it. Something like, \x1b]_;tooltip|pid:1234 ...\x07. That way we could add functions to our terminals to support known types. Example:

supported_metadata_types = {
    'tooltip': handle_tooltip,
    'mimetype': handle_mimetype,
}

Once you've got two terminal applications supporting something others will probably hop on board as well. Whatever is put together it shouldn't be HTML-specific because other types of output may make more sense in the future (you never know).

mitotic / graphterm

XSS Vulnerability #5

~line 2518: