GNOME Bugzilla – Bug 652124
malicious escape sequence causes gnome-terminal to exhaust memory
Last modified: 2011-06-14 21:53:50 UTC
[ Original report: http://bugs.debian.org/629688 by “vladz” ] When passing a huge value to the "insert-blank-characters" capability (defined in caps.c), gnome-terminal crashes (and maybe other terminals that depend on libvte9). $ cat -n vte-0.24.3/src/caps.c: [...] 418 {CSI "%d@", "insert-blank-characters", 0}, To reproduce the crash: printf "\033[100000000000000000@" This causes the terminal to consume all available memory.
Anyone feel like looking into this? Should be safe to limit any numbers read to something small, like 1024?
Just look for g_value_set_long() in table.c and trie.c. Doesn't look hard.
/* Insert N characters. */ static void vte_sequence_handler_IC (VteTerminal *terminal, GValueArray *params) { vte_sequence_handler_multiple(terminal, params, vte_sequence_handler_ic); } Just introduce a vte_sequence_handler_multiple_limited variant that limits the number to the passed max. What does xterm do here?
Created attachment 189541 [details] [review] Patch the vte_sequence_handler_IC() function
Hi, Xterm checks the parameter value inside the InsertChar() function, and sets a default value if it's to big. Where the default (limit variant) depends on the terminal size: xterm-261/util.c: [...] 972 /* 973 * Insert n blanks at the cursor's position, no wraparound 974 */ 975 void 976 InsertChar(XtermWidget xw, unsigned n) 977 { [...] 980 unsigned limit; {...] 995 limit = (unsigned) (MaxCols(screen) - screen->cur_col); 996 997 if (n > limit) 998 n = limit; The patch I've attached above does the same thing. Is this ok for you?
LGTM. Have you tested this and works?
I don't think this is the right place for this check. In vte_sequence_handler_IC it's not assured that the params[0] is a GValue with a long.
Created attachment 189650 [details] [review] patch
Fixed on vte-0-28 and master; 0.28.1 released.