You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered: