slow processing of escape sequences with large repeat counts #271

Closed
lindi2 opened this Issue May 15, 2012 · 3 comments

Comments

Projects
None yet
2 participants

lindi2 commented May 15, 2012

The commands

echo -en "\e[2147483647L"
echo -en "\e[2147483647M"
echo -en "\e[2147483647@"
echo -en "\e[2147483647P"

all cause mosh-server to enter very long for-loops in terminalfunctions.cc.

lindi2 commented May 15, 2012

Reported similar issue also against VTE at https://bugzilla.gnome.org/show_bug.cgi?id=676090

keithw closed this in 9791768 May 16, 2012

Owner

keithw commented May 16, 2012

Thanks, nice catch.

Owner

keithw commented May 22, 2012

In general, any application that can write escape sequences to the user's terminal can cause problems for the user. For example, the application can write an escape sequences to clear the screen so the user can't read anything, or move the cursor around, or flood the terminal with garbage. A faithful terminal emulator (e.g. xterm or Terminal.app) will even let the application turn off the keyboard!

Try:

echo -en "\033[2h"

in xterm or Terminal.app.

That's a DoS quite literally, but it's not a vulnerability or security problem.

Allowing the application to send the terminal emulator into chugging CPU for a long time based on 20 bytes (specifying a high repeat count) is particularly high bang for the buck, but in general we're not really trying to plug this kind of thing categorically. The user has to "trust" the application, since after all the application decides what gets displayed on the screen in the first place.

We don't believe it is exploitable by a "remote attacker," and programs that allow untrusted user-to-user communication, e.g. write(1), already need to (and do) screen out ANSI escape sequences.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment