Xterm clipboard operating system control

[GoogleCodeExporter]

small rfe, add support for xterm's clipboard OSC

paraphrasing from http://invisible-island.net/xterm/ctlseqs/ctlseqs.html

Operating System Controls
OSC 52 ; Pc ; Pd ST
OSC 52 ; Pc ; Pd BEL

-> Manipulate Selection Data.

The first parameter, Pc, is used to construct a list of selection parameters 
for clipboard, primary, select, or cut buffers (not important at all).  If the 
parameter is empty, xterm uses s 0 , to specify the configurable 
primary/clipboard selection and cut buffer 0. (Would be enough to always 
default to clipboard)

The second parameter, Pd, gives the selection data.  Normally this is a string 
encoded in base64.  The data becomes the new selection, which is then available 
for pasting by other applications. (This is important, base64 encoded data 
should be decoded and saved in the clipboard)

If the second parameter is a ? , xterm replies to the host with the selection 
data encoded using the same protocol.

Original issue reported on code.google.com by ailin.ne...@gmail.com on 8 Apr 2011 at 7:39

[GoogleCodeExporter]

Thanks for the suggestion, that's definitely something that mintty should 
support.

Original comment by andy.koppe on 8 Apr 2011 at 8:47

• Changed state: Accepted
• Added labels: Difficulty-Medium, Priority-Medium

[GoogleCodeExporter]

On second thoughts, there are serious security issues with this feature. Being 
able to read the clipboard would allow a malicious server to clandestinely 
monitor clipboard content, which may occasionally contain sensitive data. 
Setting the clipboard content would allow a server or even just a catted text 
file to get the user to inadvertently paste malicious commands. Finally, 
setting the clipboard content and immediately reading it back would allow an 
attacker to insert a malicious sequence of characters into the input stream 
right away, although at least this one is limited to the BASE64 range.

Xterm has separate options for allowing clipboard reading and writing. By 
default, writing is forbidden, but reading is allowed, so I guess the user is 
expected to accept the clipboard monitoring risk.

Obviously, adding a default-off option to mintty for allowing clipboard access 
is a possibility, but I'm not terribly comfortable with what would effectively 
be a "make my terminal really insecure" switch.

Also note that locally running programs can already access the clipboard using 
Cygwin's /dev/clipboard device or the getclip/putclip utilities.

Original comment by andy.koppe on 15 May 2011 at 2:31

• Changed state: Rejected

[GoogleCodeExporter]

I can see that it might get even dangerous in case you are running malicious 
programs that use this feature. But those malicious programs would equally be 
able to access /dev/clipboard, no? Such feature would be convenient in favour 
of the clumsy X11 forwarding and using xclip et.al. on the remote host (which 
also requires at least a half functioning X11 setup on the remote). Of course, 
only for trusted programs. What do you think?

Original comment by ailin.ne...@gmail.com on 16 May 2011 at 6:48

[GoogleCodeExporter]

Only local programs can access /dev/clipboard, and they of course have access 
to all your data anyway. Regarding remote hosts, it doesn't even require 
actively running anything malicious. Just trying to connect can be enough if 
the server has been prepared to print malicious sequences straight away. And 
there's the issue with catting files (both remote and local) as well, which you 
wouldn't expect to be able to mess up more than your terminal settings.

Unlike X servers, terminals don't know where any of the data they're displaying 
is coming from; they just see a single data stream coming from the underlying 
pseudo terminal (pty) device. Hence unfortunately there's no way to 
discriminate between trusted and untrusted programs.

Original comment by andy.koppe on 17 May 2011 at 5:07

[GoogleCodeExporter]

What I'm saying is, that if you ssh -X somewhere, and you have an X server 
running, the remote host could equally launch a malicious program to set the 
clipboard content. So to me it seems that such control would be not much more 
insecure than an X forwarding. Or am I mistaken there?

Xterm has a popup menu to enable/disable the setting on the fly, so if you see 
a trusted program on screen you can enable it.

Nevertheless the decision is yours of course.

Original comment by ailin.ne...@gmail.com on 17 May 2011 at 7:31

[GoogleCodeExporter]

Fair point regarding 'ssh -X'. However, the ssh manual has this to say on the 
matter:

"X11 forwarding should be enabled with caution.  Users with the
ability to bypass file permissions on the remote host (for the
user's X authorization database) can access the local X11 display
through the forwarded connection.  An attacker may then be able
to perform activities such as keystroke monitoring.

For this reason, X11 forwarding is subjected to X11 SECURITY
extension restrictions by default.  Please refer to the ssh −Y
option and the ForwardX11Trusted directive in ssh_config(5) for
more information."

Also, keep in mind that any text that makes it through to the terminal could 
take advantage of insecure control sequences, be that through catting an 
untrustworthy file or due to something like a mail or IRC client not filtering 
such control sequences.

Having said that, I see that rxvt-unicode has a -insecure command line switch 
for enabling problematic sequences. Perhaps that's the way forward.

Original comment by andy.koppe on 7 Jun 2011 at 6:02

• Changed title: Xterm clipboard operating system control
• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Tmux use this sequence to copy paste buffer contents into terminal clipboard.
If mintty supports this sequence, server side tmux can copy paste buffer 
contents into Windows's clipboad.
It's very useful.

Tmux blocks this sequence sent from program which runs under tmux.
I think it's secure if this sequence is used with tmux.

Original comment by sued...@gmail.com on 2 Dec 2011 at 4:39

[GoogleCodeExporter]

I'd really like to see this supported.

Note for others: hterm already supports OSC 52 escape sequence.

There is also a nice script that can be used like pbcopy, xclip and xsel.  This 
script uses osc 52 escape to get content into the terminal's OS's clipboard: 
See http://goo.gl/Xxv0pt

Original comment by darcypar...@gmail.com on 13 Dec 2013 at 8:17

[GoogleCodeExporter]

I'd really like to see this supported as well.  It sounds like iterm2, xterm, 
tmux and hterm all support clipboard sharing. 

Original comment by cbuscha...@gmail.com on 1 Jun 2014 at 2:36