Bug#787628: Bracketed paste is unsafe
I'll take this off debians bugtracker now, it really makes no sense to discuss this there (it's not a discussion forum), the bug should be reassigned to firefox and/or other programs that suffer from this security issue, as it can't be fixed in a terminal emulator. Or closed. If you want to discuss development of urxvt with me, please do so on the urxvt list (rxvt-unic...@lists.schmorp.de>), or with me privately. On Tue, Nov 17, 2015 at 02:37:54PM +0100, Yuri D'Elia wrote: > On 17/11/15 00:32, Marc Lehmann wrote: > >> Ideally, I would like the data to come through *as-is*, 8bit clean. > > > > I understand what you wish for, but I think you are trying to use the > > wrong tool here. For starters, can you define what "as-is" means when the > > data is binary and the terminal is in utf-8? Or a non-utf-8 filename? > > Encoding sits on top of the construct if we can make the paste > transparent, it won't change the current status quo. If that were true, nobody would ever have an encoding problem - the problem is, it isn't true. Grafting encoding on top of a system that doesn't support it will just result in more mojibake, not correct behaviour. I don't see a point in supporting something that is broken to begin with. The problem of bracketed paste is that people are asking for things that are badly specified, badly implemented, badly thought out and with ill-defined goals. > If we agree that the current scheme is insufficient for any purpose, > let's break it for the better. There's basically no-one using bracketed > paste currently. That could mean there is little or no demand for it. It's also not clear what the purpose of it is - everybody, including you, cites security concerns of some form as reason, i.e., they don't have a real use case. > > zsh doesn't have access to the pty master, and is unlikely to be able to > > react fast enough. > > A proper solution might actually to devise on how the pasted content > should be encoded by the bracketed paste in a way that 1) allows > embedded control sequences of any kind 2) they are escaped for the > terminal discipline to pass-though. I can't see how that would be a proper solution (see above). > In that sense, we could just encode the block in a 7bit-safe encoding > such as base64 or something more efficient. escaping or using hex would be a lot more conservative, just saying. > > The problem with this is that a large share of pastes would not benefit > > from paste mode. It's basically only _some_ multiline pastes that would > > benefit from it, while most would either not benefit or suffer negative > > effects from it. > > Not really. Bracketed paste allows to make the distinction between a > human typing and a paste, and that really makes a great difference. Such as? You make a lot of very remarkable claims, but so far have shown very little to back them - which is something in common with the faction that wants to "fix" bracketed paste. > >> Firefox has nothing to do with it here, but it shows one of the most > >> important aspects of a reliable bracketed paste: if bracketed paste is > >> implemented correctly in the terminal, proper behavior *can* be > >> implemented at the application level, as zsh now shows. > > > > Didn't you just write that zsh doesn't? And why would that be proper > > behaviour? The number of times where I paste actual commands into my > > shell completely dwarfs the few times where I paste hidden commands from > > insecure apps such as firefox - or in other words, the only way to switch > > zsh into proper mode would be to disable an option that would put it into > > "proper mode". > > zsh now enables bracketed paste by default. So you redact your claim? I am not sure what you mean with this statement, it doesn't seem to be a reply to the quoted text. > It actually sends \e[?2004l to all terminals, as the ones we tried that > didn't support bracketed paste simply swallowed the escape. Basing such behaviour on a few terminal (emulators?) you tried is hardly a good implementation. It's really just a bad hack - what's next, zsh-certified terminals, and everybody else has lost? (Hint, this only works on ansi/vt-type terminals). > A bracketed paste is also never executed by default. A newline is > inserted literally (as ^J would), so that any command can be previewed. > The paste is also quoted and the quoting style can be customized with a > prefix argument, so that you can paste into a quote with quotes being > escaped correctly, and invisible characters can always be seen. > > It's a major improvement in behavior for pasting in any sense. It would be a major step back for me, so your statement is wrong. Again, it is ea to make sweeping statements such as these, but more is needed to convince me, especially when the claims turn out to be wrong. > > I very much disagree that keeping the user from pasting text that she or > > he wants to paste is proper - it's just more bossing around because actual > > bugs (l
Bug#787628: Bracketed paste is unsafe
On 17/11/15 00:32, Marc Lehmann wrote: >> Ideally, I would like the data to come through *as-is*, 8bit clean. > > I understand what you wish for, but I think you are trying to use the > wrong tool here. For starters, can you define what "as-is" means when the > data is binary and the terminal is in utf-8? Or a non-utf-8 filename? Encoding sits on top of the construct if we can make the paste transparent, it won't change the current status quo. >> Without filtering the termination sequence at all, there's *no* way to >> implement reliably *any* bracketed sequence. It *is* the job of the >> terminal program to filter the sequence, and only that sequence, from >> the paste. This is not sanitization of the input, it's just protocol. > > And with filtering it is also not possible to implement this "reliably". Very true, but I'm absolutely open to discuss on how to fix that. If we agree that the current scheme is insufficient for any purpose, let's break it for the better. There's basically no-one using bracketed paste currently. To answer with the following: >> I'd rather try to manually change and restore the terminal mode through >> the pty master in order for the bracketed paste to be fully transparent >> for all programs, but I didn't get to it yet. > > zsh doesn't have access to the pty master, and is unlikely to be able to > react fast enough. No, the attached program will never be able to do that reliably. The terminal needs to do that, if possible, but even that would break down in the context of a remote pty. A proper solution might actually to devise on how the pasted content should be encoded by the bracketed paste in a way that 1) allows embedded control sequences of any kind 2) they are escaped for the terminal discipline to pass-though. In that sense, we could just encode the block in a 7bit-safe encoding such as base64 or something more efficient. > The problem with this is that a large share of pastes would not benefit > from paste mode. It's basically only _some_ multiline pastes that would > benefit from it, while most would either not benefit or suffer negative > effects from it. Not really. Bracketed paste allows to make the distinction between a human typing and a paste, and that really makes a great difference. >> Firefox has nothing to do with it here, but it shows one of the most >> important aspects of a reliable bracketed paste: if bracketed paste is >> implemented correctly in the terminal, proper behavior *can* be >> implemented at the application level, as zsh now shows. > > Didn't you just write that zsh doesn't? And why would that be proper > behaviour? The number of times where I paste actual commands into my > shell completely dwarfs the few times where I paste hidden commands from > insecure apps such as firefox - or in other words, the only way to switch > zsh into proper mode would be to disable an option that would put it into > "proper mode". zsh now enables bracketed paste by default. It actually sends \e[?2004l to all terminals, as the ones we tried that didn't support bracketed paste simply swallowed the escape. A bracketed paste is also never executed by default. A newline is inserted literally (as ^J would), so that any command can be previewed. The paste is also quoted and the quoting style can be customized with a prefix argument, so that you can paste into a quote with quotes being escaped correctly, and invisible characters can always be seen. It's a major improvement in behavior for pasting in any sense. > This is going the same path as firefox - instead of plugging javascript > security holes, we get kludges (such as disabling file urls because > firefox can't guarantee their safety, or randomly renaming your profile > directory instead of keeping javascript from snooping around in your > filesystem). > > I very much disagree that keeping the user from pasting text that she or > he wants to paste is proper - it's just more bossing around because actual > bugs (like the one in firefox) don't get fixed. I doubt firefox will ever be able to fix this issue in a way that makes "copying" safe. Frankly, I do not care, as unicode issues will always be present. Let's fix bracketed paste.
Bug#787628: Bracketed paste is unsafe
On Mon, Nov 16, 2015 at 04:46:07PM +0100, Yuri D'Elia wrote: > The way I see it, bracketed paste allows the program attached to the tty > to receive clean input from the paste without the terminal interfering. > > Ideally, I would like the data to come through *as-is*, 8bit clean. I understand what you wish for, but I think you are trying to use the wrong tool here. For starters, can you define what "as-is" means when the data is binary and the terminal is in utf-8? Or a non-utf-8 filename? > Without filtering the termination sequence at all, there's *no* way to > implement reliably *any* bracketed sequence. It *is* the job of the > terminal program to filter the sequence, and only that sequence, from > the paste. This is not sanitization of the input, it's just protocol. And with filtering it is also not possible to implement this "reliably". > Bracketed paste might actually be used by editors, such as vim, to > insert text as-is without having to enter "paste" mode first. The problem with this is that a large share of pastes would not benefit from paste mode. It's basically only _some_ multiline pastes that would benefit from it, while most would either not benefit or suffer negative effects from it. > We've been discussing the issue of break processing in the zsh ml, and > > I'd rather try to manually change and restore the terminal mode through > the pty master in order for the bracketed paste to be fully transparent > for all programs, but I didn't get to it yet. zsh doesn't have access to the pty master, and is unlikely to be able to react fast enough. > I don't want to go through the route of xterm, which instead filters the > input "pretending" to know what is safe and what isn't, which like you > say, is just guessing. The problem isn't that it is guessing, the problem is that is always wrong - if a program sends different text when asked for a selection then what the user has selected, this is a bug, which can be security-relevant. No amount of kludging or guessing or following protocol can fix this in a terminal emulator, unless the temrinal emulator suffers from the same problem. > Firefox has nothing to do with it here, but it shows one of the most > important aspects of a reliable bracketed paste: if bracketed paste is > implemented correctly in the terminal, proper behavior *can* be > implemented at the application level, as zsh now shows. Didn't you just write that zsh doesn't? And why would that be proper behaviour? The number of times where I paste actual commands into my shell completely dwarfs the few times where I paste hidden commands from insecure apps such as firefox - or in other words, the only way to switch zsh into proper mode would be to disable an option that would put it into "proper mode". This is going the same path as firefox - instead of plugging javascript security holes, we get kludges (such as disabling file urls because firefox can't guarantee their safety, or randomly renaming your profile directory instead of keeping javascript from snooping around in your filesystem). I very much disagree that keeping the user from pasting text that she or he wants to paste is proper - it's just more bossing around because actual bugs (like the one in firefox) don't get fixed. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#787628: Bracketed paste is unsafe
Sorry for the late reply, but as I wasn't included in the reply, I didn't get any notification. I just stumbled upon it today by chance... > First of all, the safety is not the same as security, and the bracketed > paste mode is not a means for security (for a variety of subreasons, the > main being that pasting a _shell_ command that contains data that the user > doesn't know is insecure with or without bracketed paste mode filtering > out certain sequences). The way I see it, bracketed paste allows the program attached to the tty to receive clean input from the paste without the terminal interfering. Ideally, I would like the data to come through *as-is*, 8bit clean. Unfortunately, bracketed paste is flawed, as it relies on a termination sequence and doesn't allow escapes. This means that even if I wanted to, I cannot pass input that includes the termination sequence. Without filtering the termination sequence at all, there's *no* way to implement reliably *any* bracketed sequence. It *is* the job of the terminal program to filter the sequence, and only that sequence, from the paste. This is not sanitization of the input, it's just protocol. > Third, even if bracketed paste mode would single out this sequence, it's > not a security feature, as the user has no feedback on whether this mode > is enabled, so cannot base her decision to paste on this mode. Advertising > bracketed paste mode as a security feature would trick users into unsafe > behaviour. This patch was produced as a result of some work in zsh, which now uses bracketed paste to automatically quote (and not execute by default!) pastes. This is now the default behavior in zsh since 5.1. Bracketed paste might actually be used by editors, such as vim, to insert text as-is without having to enter "paste" mode first. However, bracketed paste needs to be reliable. > Lastly, guessing what is "safe" and what is "unsafe" in the terminal > emulator is the wrong place, as it can't know what the application > interprets. For example, the application might abort paste mode on other > sequences as well (such as ctrl-c). It's also very difficult to implement, > even if there was a list of what is to be filtered out, as the patch > shows, which doesn't manage to filter out sequences at internal borders, so > not giving the false impression that pasting is safe no matter what it > contains. We've been discussing the issue of break processing in the zsh ml, and indeed the patch is still "incomplete" in the sense that Ctrl+C is still processed by the terminal discipline, and that's definitely something that should be avoided. I'd rather try to manually change and restore the terminal mode through the pty master in order for the bracketed paste to be fully transparent for all programs, but I didn't get to it yet. I don't want to go through the route of xterm, which instead filters the input "pretending" to know what is safe and what isn't, which like you say, is just guessing. > Therefore, I would suggest reassigning this to firefox or other > applications in Debian GNU/Linux that let you select one text visually, > but then offer a different text as the selection to other apps, as that is > indeed a security problem. Firefox has nothing to do with it here, but it shows one of the most important aspects of a reliable bracketed paste: if bracketed paste is implemented correctly in the terminal, proper behavior *can* be implemented at the application level, as zsh now shows.
Bug#787628: Bracketed paste is unsafe
Hi! This bugreport is unsound for a variety of reasons. First of all, the safety is not the same as security, and the bracketed paste mode is not a means for security (for a variety of subreasons, the main being that pasting a _shell_ command that contains data that the user doesn't know is insecure with or without bracketed paste mode filtering out certain sequences). Secondly, it's not rxvt-unicode's job to implement the security barrier between e.g. the interwebs and your selection - if an app such as firefox allows one to select text and then internally selects something else (as firefox indeed does), then this is a security issue in the application that can be tricked into putting text into the selection that the user didn't select. Third, even if bracketed paste mode would single out this sequence, it's not a security feature, as the user has no feedback on whether this mode is enabled, so cannot base her decision to paste on this mode. Advertising bracketed paste mode as a security feature would trick users into unsafe behaviour. Lastly, guessing what is "safe" and what is "unsafe" in the terminal emulator is the wrong place, as it can't know what the application interprets. For example, the application might abort paste mode on other sequences as well (such as ctrl-c). It's also very difficult to implement, even if there was a list of what is to be filtered out, as the patch shows, which doesn't manage to filter out sequences at internal borders, so not giving the false impression that pasting is safe no matter what it contains. Therefore, I would suggest reassigning this to firefox or other applications in Debian GNU/Linux that let you select one text visually, but then offer a different text as the selection to other apps, as that is indeed a security problem. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787628: Bracketed paste is unsafe
> Therefore, I would suggest reassigning this to firefox or other As an additional fyi, firefox upstream bug https://bugzilla.mozilla.org/show_bug.cgi?id=637895(*) is reasonably close (as it is about the same problem). (*) Thanks to Mikael (of zsh fame) for pointing this out. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787628: Bracketed paste is unsafe
Package: rxvt-unicode
Version: 9.21-1
Severity: important
Tags: security upstream patch
This is not really news as this is an age-old attack with low impact:
rxvt-unicode does not filter end sequences when using bracketed paste mode. You
can try this by following this web page:
https://thejh.net/misc/website-terminal-copy-paste
and using the oh-my-zsh "safe-paste" plugin. Pasted data can escape the
bracketed mode, which might result in unsafe input.
This is confirmed by fetching urxvt source and seeing the definition of
rxvt_term::tt_paste in screen.C.
Patch attached.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (900, 'unstable'), (800, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages rxvt-unicode-256color depends on:
ii base-passwd 3.5.37
ii libc6 2.19-18
ii libfontconfig12.11.0-6.3
ii libfreetype6 2.5.2-4
ii libgcc1 1:5.1.1-8
ii libgdk-pixbuf2.0-02.31.4-2
ii libglib2.0-0 2.44.1-1
ii libperl5.20 5.20.2-6
ii libstartup-notification0 0.12-4
ii libx11-6 2:1.6.3-1
ii libxft2 2.3.2-1
ii libxrender1 1:0.9.8-1+b1
ii ncurses-term 5.9+20150516-2
Versions of packages rxvt-unicode-256color recommends:
ii fonts-vlgothic [fonts-japanese-gothic] 20141206-1
pn ttf-dejavu
rxvt-unicode-256color suggests no packages.
--- src/screen.C.Orig 2015-06-03 14:56:51.698258870 +0200
+++ src/screen.C 2015-06-03 15:51:27.213488209 +0200
@@ -2706,8 +2706,17 @@
data[i] = C0_CR;
if (priv_modes & PrivMode_BracketPaste)
+ {
tt_printf ("\x1b[200~");
+/* filter end sequence from the input data */
+while (char* p = (char*)memmem (data, len, "\x1b[201~", 6))
+{
+ len -= 6;
+ memmove (p, (p + 6), len - (p - data));
+}
+ }
+
tt_write (data, len);
if (priv_modes & PrivMode_BracketPaste)
