
SCI and the “62;c62;” attack - eaguyhn
https://www.polydesmida.info/BASHing/2018-08-25.html
======
userbinator
9A is
[https://en.wikipedia.org/wiki/%C5%A0](https://en.wikipedia.org/wiki/%C5%A0)
in CP1252, which is probably what it was meant to be.

According to
[https://en.wikipedia.org/wiki/C0_and_C1_control_codes](https://en.wikipedia.org/wiki/C0_and_C1_control_codes)
the function of this byte is "To be followed by a single printable character
(0x20 through 0x7E) or format effector (0x08 through 0x0D). The intent was to
provide a means by which a control function or a graphic character that would
be available regardless of which graphic or control sets were in use could be
defined. Definitions of what the following byte would invoke was never
implemented in an international standard."

It's not a VT100 escape code either, so it's a bit odd that it would just
cause the termulator to hang.

~~~
spc476
VT100 escape codes are a subset of ECMA-48, which does define (somewhat) SCI
(SINGLE CHARACTER INTRODUCER) which can be encoded as 0x96 or <ESC>Z.

------
abbeyj
I can only get this to work in the Gnome terminal with the sequence C2 9A, not
with just 9A alone. This is likely related to UTF-8. If your terminal emulator
was configured for Latin-1 or something instead of UTF-8 perhaps you wouldn't
need the C2 prefix. Note that C2 9A becomes U+009A after UTF-8 decoding.

The terminal is actually sending back the sequence "\e[?62;c". The "\e[?" part
gets eaten by the line editor and "62;c" shows up as input. Note that despite
the claims in the article you _are_ returned to the shell prompt it is just
that it has some garbage in the input buffer. You can remove this by
backspacing it or you can hit Ctrl+C, etc.

A little Googling produces
[https://vt100.net/docs/vt220-rm/chapter4.html#S4.17.1](https://vt100.net/docs/vt220-rm/chapter4.html#S4.17.1)
. This feature was designed to let the server interrogate your terminal for
the features it supports. The server would send "\e[c" and then it would wait
for a response in the form "\e[?...c" where the "..." part indicates the
terminal capabilities. And indeed, that does work as expected:

    
    
      $ echo -ne '\e[c'; read -r -s -t 1 -n 99; echo -n $REPLY | xxd -g1
      00000000: 1b 5b 3f 36 32 3b 63                             .[?62;c
    

If we look down a little more in that page
([https://vt100.net/docs/vt220-rm/chapter4.html#S4.17.3](https://vt100.net/docs/vt220-rm/chapter4.html#S4.17.3))
we can see that there is an alternate sequence which also returns this
response and it is "\eZ". This is "not recommend[ed]" and it looks like it is
actually only supported for backward compatibility with the VT52. That
sequence also behaves as expected:

    
    
      $ echo -ne '\eZ'; read -r -s -t 1 -n 99; echo -n $REPLY | xxd -g1
      00000000: 1b 5b 3f 36 32 3b 63                             .[?62;c
    

But we're not sending either "\e[c" or "\eZ". Somehow we're getting this
answer back in response to "\xC2\x9A" instead. Gnome terminal (and probably
the XFCE terminal) uses libvte for its terminal handling. If we look in the
source we find this interesting comment:

    
    
      /* Escape sequences from \e@ to \e_ have a C1 counterpart
       * with the eighth bit set instead of a preceding '\x1b'.
       * This is encoded in the current encoding, e.g. in UTF-8
       * the C1 CSI (U+009B) becomes \xC2\x9B.
       *
       * When matching, the bytestream is already decoded to
       * Unicode codepoints.  In the "code" string, each byte
       * is interpreted as a Unicode codepoint (in other words,
       * Latin-1 is assumed).  So '\x80' .. '\x9F' bytes
       * (e.g. the byte '\x9B' for CSI) are the right choice here.
       *
       * For each sequence containing N occurrences of \e@ to \e_,
       * we create 2^N variants, by replacing every subset of them
       * with their C1 counterpart.
       */
    

I think this is saying that instead of "\e[" (aka "\e\x5B") it will also
accept "\x9B" (or "\xC2\x9B" in UTF-8). Which means that "\eZ" (aka "\e\x5A")
would have an alias of "\x9A" (or "\xC2\x9A" in UTF-8). So I think that
explains how this all happens:

\- "\xC2\x9A" gets UTF-8 decoded into 9A

\- 9A gets treated as an alias for "\eZ"

\- "\eZ" is an old VT52 sequence which causes the terminal to answer back with
its capabilities.

See also
[https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/...](https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/sci-
is-not-decid.html) for how PuTTY used to do the same thing but now no longer
does.

~~~
rwmj
Fun fact: qemu (actually the sgabios in qemu) sends the ESC [ 6 n sequence to
query the terminal and waits for 0.26 seconds for a response before timing
out.

In libguestfs I added code to "answer" this query, to shave 260 milliseconds
off boot times:

[https://github.com/libguestfs/libguestfs/blob/0d0b5511309182...](https://github.com/libguestfs/libguestfs/blob/0d0b5511309182f163ae263e862ddb0235780917/lib/conn-
socket.c#L369)

