A look at terminal emulators, part 1

Posted Mar 31, 2018 23:22 UTC (Sat) by domo (guest, #14031)
In reply to: A look at terminal emulators, part 1 by anarcat
Parent article: A look at terminal emulators, part 1

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.