A look at terminal emulators, part 1

Posted Mar 31, 2018 7:26 UTC (Sat) by jwilk (subscriber, #63328)
In reply to: A look at terminal emulators, part 1 by anarcat
Parent article: A look at terminal emulators, part 1

<html>$ echo Hello <span style="position: absolute; left: -100px; top: -100px">| cowsay pwned&#15;</span> world</html>

(Tested with Firefox 52.7.3 + urxvt 9.22 + bash 4.4.18)

A look at terminal emulators, part 1

Posted Mar 31, 2018 15:48 UTC (Sat) by anarcat (subscriber, #66354) [Link] (12 responses)

You mean like this?

https://paste.anarc.at/control-o-hack.html

Here copy-pasting this with the middle mouse button doesn't execute any code in urxvt: the ^O shows up on screen, but doesn't seem to cause the code to execute, nor does it cause the confirm-paste plugin to fire.

A look at terminal emulators, part 1

Posted Mar 31, 2018 21:48 UTC (Sat) by jwilk (subscriber, #63328) [Link] (11 responses)

Do you have bracket paste enabled in inputrc? My exploit doesn't defeat it, although it could. It's a matter of adding [201~ before .

A look at terminal emulators, part 1

Posted Mar 31, 2018 22:20 UTC (Sat) by anarcat (subscriber, #66354) [Link] (10 responses)

I do, and you are correct that adding that string defeats it. I have modified my test page and it unfortunately seems to bypass confirm-paste in urxvt:

https://paste.anarc.at/control-o-hack.html

i had to tweak it a little because the leading dollar sign would get parsed by bash and confuse things a little (although cowsay would still be called)

so, i guess this should be reported against urxvt as well eh...

A look at terminal emulators, part 1

Posted Mar 31, 2018 23:22 UTC (Sat) by domo (guest, #14031) [Link] (8 responses)

I can confirm this bypass works when running *zsh* on urxvt (with (chomp-and)-confirm-paste -- chomp removing trailing newline, not sure in original plugin or whether I added it myself) :/

A look at terminal emulators, part 1

Posted Mar 31, 2018 23:42 UTC (Sat) by domo (guest, #14031) [Link] (6 responses)

Hmm, no editing... so...

added $str =~ tr/\033//d; to my confirm-paste copy and this particular exploit is not effective anymore...

A look at terminal emulators, part 1

Posted Mar 31, 2018 23:54 UTC (Sat) by domo (guest, #14031) [Link]

Ok, I did have my own version, for which I used some amount of time to figure out.
Here is the full diff compared to confirm-paste in urxvt github repository:

--- Downloads/confirm-paste.txt 2018-04-01 02:49:34.886913091 +0300
+++ dotdir/urxvt/chomp-and-confirm-paste 2018-04-01 02:40:11.030578963 +0300
@@ -21,9 +21,14 @@
sub on_tt_paste {
my ($self, $str) = @_;

+ chomp $str; $str =~ tr/\033//d;
+
my $count = ($str =~ tr/\012\015//);

- return unless $count;
+ unless ($count) {
+ $self->tt_paste ($str);
+ return 1;
+ }

$self->{paste} = \$str;
$self->msg ("Paste of $count lines, continue? (y/n)");

A look at terminal emulators, part 1

Posted Apr 2, 2018 8:41 UTC (Mon) by jwilk (subscriber, #63328) [Link] (4 responses)

Enumerating badness usually doesn't end well. There are other control sequences that could be used for code execution (^[^E and ^X^E at least). Proof of concept exploits:

$({ echo; cowsay pwned; }>&2)[201~
[201~Dicowsay pwnedZZ

The latter works only if your editor is terminal-based and uses vi keybindings.

A look at terminal emulators, part 1

Posted Apr 3, 2018 14:12 UTC (Tue) by anarcat (subscriber, #66354) [Link] (3 responses)

how about just triggering confirm-paste on any control sequence at all? we have a range for those and while it *is* enumerating badness (somewhat), it seems to me it could just be enough for our cases...

A look at terminal emulators, part 1

Posted Apr 3, 2018 21:30 UTC (Tue) by domo (guest, #14031) [Link] (1 responses)

so perhaps

my $count = ($str =~ tr/[\0-\010\012-\037]//);

i.e. all ascii codes below 32 except tab, to trigger confirm-paste.

A look at terminal emulators, part 1

Posted Apr 4, 2018 13:39 UTC (Wed) by mgedmin (subscriber, #34497) [Link]

I would also be careful about \233 (CSI). IIRC there are terminal modes (S8C1T) where function keys and such send sequences prefixed with \233 (CS) instead of \033 [ (ESC [).

A look at terminal emulators, part 1

Posted Apr 5, 2018 6:56 UTC (Thu) by pabs (subscriber, #43278) [Link]

An option to always review paste contents would be nice to have in all terminal emulators IMO.

Personally I tend to paste into a GUI text editor before pasting into the terminal.

I sometimes wonder if anyone did any fuzzing of paste routines in those editors.

A look at terminal emulators, part 1

Posted Apr 12, 2018 12:24 UTC (Thu) by okapi (guest, #111261) [Link]

On zsh, the Ctrl-O is inserted literally. Are you perhaps still using the ancient oh-my-zsh safe-mode plugin? Since version 5.1, zsh has supported bracketed-paste natively without any plugins. The native support has significant advantages like also working from incremental history searches. It's enabled by default which was rather controversial, at least to begin with. To see if you have it check with typeset -p zle_bracketed_paste

If bash inteprets a Ctrl-O, even with enable-bracketed-paste then that's a readline bug. More likely, your configuration is wrong somehow. In my testing, I get a literal ^O in the line.

A look at terminal emulators, part 1

Posted Apr 22, 2018 8:06 UTC (Sun) by jwilk (subscriber, #63328) [Link]

> i guess this should be reported against urxvt

Bracked paste bypass was reported in 2015: https://bugs.debian.org/787628

Apparently upstream is not interested in fixing it.