On Fri, 31 Oct 2025 at 17:15, Michael Paoli <[email protected]> wrote: > On Fri, Oct 31, 2025 at 6:42 AM Nicolas George <[email protected]> wrote: > > Vincent Lefevre (HE12025-10-31):
> > > But that's potentially insecure as this could yield arbitrary > > > escape sequences to the terminal, which could do bad things. > > That has been disabled for eons. > Some of us still have terminal(s) that are "eons" old. > E.g. My Cromemco C3102 terminal, it has various such control/escape > sequences. > One of them basically says interpret the following as hex data to be > loaded into RAM, load it into RAM, and run it (the C3102 is a relatively > intelligent terminal for its day, and has a 6502 microprocessor in it > - and of course [E[E]]PROM(s) and RAM). > And many terminals will commonly have control/escape sequences that tell > the terminal to output some or all of the content on the screen - those > were the most common such control/escape sequences to be exploited, e.g. > data to clear the screen enter a command one wants the victim user to > execute, e.g. to compromise their account, or the host, send sequence to > tell the terminal to output its screen contents, that contents is then > sent, quite as if the user had typed it in on the keyboard. > So, sure, these days, those aren't as much a concern as they once were, > but the concerns are also not entirely moot, as one can't necessarily > ensure what type of terminal or emulation is/isn't or will/won't be used > or ever used. That's interesting, thanks. On Fri, 31 Oct 2025 at 17:43, Vincent Lefevre <[email protected]> wrote: > On 2025-10-31 10:14:06 -0700, Michael Paoli wrote: > > On Fri, Oct 31, 2025 at 6:42 AM Nicolas George <[email protected]> wrote: > > > Vincent Lefevre (HE12025-10-31): > > > > But that's potentially insecure as this could yield arbitrary > > > > escape sequences to the terminal, which could do bad things. > > > That has been disabled for eons. > > Some of us still have terminal(s) that are "eons" old. > And one can make xterm on trixie (not that old) crash: > xterm -k8 -e 'printf "\x9a\x85\x08"; sleep 2' Thanks for the runnable demo! I *really* like demos for shell related discussions, because a big part of my learning process about the shell came from people providing little runnable examples like this. I think it's a great way to communicate. So I tried that on bookworm, and it crashed as you say. But then I ran 'xterm -k8' and tried it to use your example to make it crash, here's a transcript: ------------------------- $ cat /etc/debian_version 12.12 $ echo $BASH_VERSION 5.2.15(1)-release $ >$'\x9a\x85\x08' $ ls ''$'\232\205\b' $ echo * $ # I pressed enter here $ # still seems to be working, no crash ------------------------- When I copied and pasted the above into vim to write this message, I can see that the 'echo *' did output the bytes <9a><85>. I guess there might have also been a bell <08> that I did not hear (for whatever reason, that's not important). But the xterm did not crash, it continued to function. So that made your demo less convincing to me, I was hoping it would crash. Do you have a better example? Why did you choose the bytes \x9a\x85\x08 ?
