On Mon, Mar 04, 2024 at 10:24:36PM +0200, Tommi Hirvola wrote: > On Mon, Mar 04, 2024 at 01:55:29PM +0100, Hiltjo Posthuma wrote: > > I'm not sure about it. You could still chain REP sequences and "DoS" it. > > Fortunately, chained REP sequences can be terminated with ^C. You can > try this by copy-pasting the following line into st and pressing CTRL+C: > > $ for i in $(seq $((2147483647/65536))); do printf 'L\033[65535b'; done > > This also works if we cat a file containing 'L\033[65535b' x 32768. Note > that ^C doesn't work for printf 'L\033[2147483647b' with (unpatched) st. > > > For untrusted input one should be careful about escape sequences anyway. > > This seems to be the unfortunate reality for modern terminals. > > Personally I use st because I can be reasonably confident that cat'ing > server log files does not lead to code execution or other unexpected > behavior. This "REP DoS issue" (if we can call it that) is the only > problem that I've encountered so far. > > Even if this REP thing is not a security issue, I think it is still > important to fix in order to prevent (rare) accidental freezing of st. > xterm seems to similarly limit REP argument to ~55K characters in my > environment. >
Hi again, OK that last part convinced me :). I also tested and looked at the xterm code and it seems to indeed limit certain parameter values to 65535. I pushed the patch. Thanks, > -- > Tommi Hirvola > -- Kind regards, Hiltjo
