GNOME Bugzilla – Bug 676090
malicious escape sequences can cause denial of service
Last modified: 2014-04-06 17:46:57 UTC
The commands echo -en "\e[2147483647L" echo -en "\e[2147483647M" echo -en "\e[2147483647P" all seem to cause gnome-terminal (vte) to use all available cpu time and stop responding to the user. Even File->Close Window can not be used.
Confirmed.
We should limit the numbers we parse to something reasonable. Not sure what's reasonable. Say, 10000 or something...
How about using the terminal size as a limit?
I guess we should do as xterm do in limiting the number, e.g. : for insert-lines: http://anonscm.debian.org/gitweb/?p=pkg-xorg/app/xterm.git;a=blob;f=util.c;h=3b4f2bc6cfc559b1dfce23ac0dcd4a8b93d06997;hb=HEAD#l880 for delete-lines: http://anonscm.debian.org/gitweb/?p=pkg-xorg/app/xterm.git;a=blob;f=util.c;h=3b4f2bc6cfc559b1dfce23ac0dcd4a8b93d06997;hb=HEAD#l950 and for delete-characters: http://anonscm.debian.org/gitweb/?p=pkg-xorg/app/xterm.git;a=blob;f=util.c;h=3b4f2bc6cfc559b1dfce23ac0dcd4a8b93d06997;hb=HEAD#l1137
I was thinking about changing the number parsing in the generic parsing layer. Who knows what other control sequences can be exploited the same way? Otherwise, yes, for specific sequences we should match xterm.
Right, a general limiting in the parsing is a good idea too.
mosh just settled for a hard limit: https://github.com/keithw/mosh/issues/271
Created attachment 214449 [details] [review] emulation: Limit integer arguments to 65535 To guard against malicious sequences containing excessively big numbers, limit all parsed numbers to 16 bit range. Doing this here in the parsing routine is a catch-all guard; this doesn't preclude enforcing more stringent limits in the handlers themselves.
Created attachment 214450 [details] [review] emulation: Limit repetitions Don't allow malicious sequences to cause excessive repetitions.
LGTM.
Fixed on vte-0-32 and vte-next.