Re: The ls command
On Fri, 31 Oct 2025 at 17:15, Michael Paoli <michael.paoli@berkeley.edu> wrote:
> On Fri, Oct 31, 2025 at 6:42 AM Nicolas George <george@nsup.org> 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 <vincent@vinc17.net> wrote:
> On 2025-10-31 10:14:06 -0700, Michael Paoli wrote:
> > On Fri, Oct 31, 2025 at 6:42 AM Nicolas George <george@nsup.org> 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 ?
Reply to: