Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

slow processing of escape sequences with large repeat counts #271

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

slow processing of escape sequences with large repeat counts #271

lindi2 opened this issue May 15, 2012 · 3 comments
Labels

Comments

@lindi2
Copy link

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
Copy link
Author

lindi2 commented May 15, 2012

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

@keithw keithw closed this as completed in 9791768 May 16, 2012
@keithw
Copy link
Member

keithw commented May 16, 2012

Thanks, nice catch.

@keithw
Copy link
Member

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
Labels
Projects
None yet
Development

No branches or pull requests

2 participants