A look at terminal emulators, part 1 [LWN.net]

A look at terminal emulators, part 1

Posted Mar 30, 2018 20:17 UTC (Fri) by jwilk (subscriber, #63328)
Parent article: A look at terminal emulators, part 1

The confirm-paste plugin won't necessarily save you from malicious pastes. In bash, ^O causes code execution, but it's not detected by the plugin.

to post comments

A look at terminal emulators, part 1

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

Interesting. I didn't know about ^O, and I didn't know it bypassed confirm-paste either... Do you have a reproducer for that? I tried to inject the control sequence in Horn's test site, but couldn't trigger the bug...

This would certainly be worth reporting upstream. In fact, ideally, I would have done with the other articles I wrote here and reported this issue in *all* the terminals, but really, that means a *lot* of (possibly controversial) bug reports... :)

A look at terminal emulators, part 1

Posted Mar 31, 2018 7:26 UTC (Sat) by jwilk (subscriber, #63328) [Link] (13 responses)

<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 (guest, #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.

A look at terminal emulators, part 1

Posted Mar 31, 2018 9:14 UTC (Sat) by tpo (subscriber, #25713) [Link]

I've reported the 'bracketed paste' security problem here: https://bugs.kde.org/show_bug.cgi?id=392554 along with jwilk's ^O problem.

A look at terminal emulators, part 1

Posted Apr 1, 2018 18:17 UTC (Sun) by xtifr (guest, #143) [Link] (2 responses)

If you don't use ^O (which seems likely if you didn't know it existed), you should be able to remap the key to something else without any problems, either using bash's "bind" command or, more generally, using .inputrc.

Not a universal solution, I realize, but should provide a good stopgap, if you're personally worried about this.

A look at terminal emulators, part 1

Posted Apr 2, 2018 7:01 UTC (Mon) by tpo (subscriber, #25713) [Link] (1 responses)

In the case of bash unbinding ^O would be:

bind -r "^O"

You need to enter the "^O" there as CTRL-v CTRL-o.

A look at terminal emulators, part 1

Posted Apr 2, 2018 7:38 UTC (Mon) by xtifr (guest, #143) [Link]

bind -r "\C-o" works for me.

It's a little confusing that it doesn't use the same syntax as .inputrc, but such is life...

You can also say "bind -u operate-and-get-next" to remove the binding of that function from *all* keys.

Though honestly, now that I look at it, it's a handy command I wish I'd known about before, and I may end up binding it to some other key, despite it's (relatively mild) danger.

Other related discussions and possible CVEs

Posted Apr 9, 2018 21:27 UTC (Mon) by anarcat (subscriber, #66354) [Link]

As it turns out, this specific issue was discussed elsewhere before. A friend pointed me towards this discussion. As it turns out, the conclusion was basically "meh, we know":

This is posted here every few months. Frankly, there's a lackluster care in fixing this in these terminals. For terminals, here's a decent avenue (gnome-terminal as example): https://turbochaos.blogspot.com/2014/08/journalctl-terminal-escape-injection.html

That latter thread is even more disturbing, in a way...