392554 2018-03-31 09:12:20 +0000 security: escaping from bracketed paste seems to be possible 2022-01-11 00:09:07 +0000 1 1 2 Applications konsole copy-paste 17.12.2 Other Linux CONFIRMED NOR normal --- 1 tpo_deb konsole-bugs-null dean gabrielfernnd j jbb martin.sandsmark ninjalj simonandric5 0 oldest_to_newest 1742173 0 tpo_deb 2018-03-31 09:12:20 +0000 According to a recent LWN article, escaping 'bracketed paste' seems to be possible in konsole: https://lwn.net/Articles/749992/. Another way to escape 'bracketed paste' seems to be ^O which makes bach execute the current line: https://lwn.net/Articles/750630/ 1742340 1 egmont 2018-03-31 20:34:11 +0000 I can't access the first article, but I guess it points out that the paste buffer might contain the terminating sequence of bracketed paste (\e[201~) which then pastes the rest without being bracketed. I can confirm this bug. I don't understand the second one: similarly to the one who responded there, I get a literal ^O printed in bash. FYI: relevant gnome-terminal (vte) issues are: https://bugzilla.gnome.org/show_bug.cgi?id=753197 https://bugzilla.gnome.org/show_bug.cgi?id=794653 1742359 2 tpo_deb 2018-03-31 22:00:26 +0000 > I can't access the first article I was assuming wrongly, I am very sorry - here are the relevant parts from the article: "Unfortunately, Horn's test page [http://thejh.net/misc/website-terminal-copy-paste] also shows how to bypass this protection, by including the end-of-pasted-text sequence in the pasted text itself, thus ending the bracketed mode prematurely. [...] in my tests, Konsole fails to properly escape the second test, even with .inputrc properly configured ['set enable-bracketed-paste on' in ~/.inputrc]" (Antoine Beaupré) And: "In bash, ^O causes code execution. [Such as:] <html>$ echo Hello <span style="position: absolute; left: -100px; top: -100px">| cowsay pwned</span> world</html> 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 ." (Jakub Wilk) 1742361 3 egmont 2018-03-31 22:04:34 +0000 > [...] It's a matter of adding [201~ before . Well, if you can escape from bracketed paste mode then of course later on you can do all sorts of nasty things. I don't even see the need for the ^O trick, the same can be achieved using a regular newline. 1743348 4 dean 2018-04-05 14:55:12 +0000 FYI, here is a link to the article for non-subscribers (Note: meets their acceptable use policy for links bypassing the paywall): https://lwn.net/SubscriberLink/749992/d3a6b4d1e90c2f39/ 1743711 5 khindenburg 2018-04-07 15:44:50 +0000 https://commits.kde.org/konsole/0b482990279d6684089a404df7473f0354c284c3 remove all ESC from bracketed paste 1749434 6 cfeck 2018-05-02 01:54:21 +0000 Kurt, does the commit from comment #5 fix this issue? 2023839 7 gabrielfernnd 2021-04-09 14:40:12 +0000 I found that if you clear konsole with (ctrl + shift + k) bracketed-paste doesn't work anymore in the now-cleared terminal. Unless you reset the terminal. 2045414 8 martin.sandsmark 2021-07-06 12:46:02 +0000 CCing Jonah on this as well since he refactored the copy&paste code. But I think it might be a duplicate? 2091890 9 ninjalj 2022-01-11 00:09:07 +0000 (In reply to Gabriel Fernandes from comment #7) > I found that if you clear konsole with (ctrl + shift + k) bracketed-paste > doesn't work anymore in the now-cleared terminal. Unless you reset the > terminal. ctrl + shift + k (clear scrollback and reset) does a hard reset (RIS - Reset to Initial State), which, among many other things, resets the bracketed-paste mode. xterm does the same if you select "Reset and Clear Saved Lines" from its ctrl+middle click menu. Both bash and zsh apparently re-enable bracketed-paste as soon as they can print a prompt.