Ubuntu 21.10 (Impish Indri) released

Posted Oct 17, 2021 19:03 UTC (Sun) by NYKevin (subscriber, #129325)
In reply to: Ubuntu 21.10 (Impish Indri) released by ibukanov
Parent article: Ubuntu 21.10 (Impish Indri) released

This is only a problem to the extent that the remote system is untrusted. While I agree that some people do need to SSH into untrusted systems, that is not a problem which I personally care about, so I'm really not enthused with the "for security reasons, we must not support OSC 52 at all" approach.

IMHO the correct way for this to work is for SSH to filter these sequences depending on a policy which the user can set, and gnome-terminal should blindly pass through anything which SSH gives it. My rationale:

1. In principle, SSH can already read the local system's clipboard anyway, because it is running on the local system. So gnome-terminal is not functioning as a security boundary in the first place. If we really wanted to, we could have SSH recognize and implement OSC 52 sequences behind gnome-terminal's back (but then SSH would need to be in the business of interfacing with X and Wayland, which is probably undesirable).
2. Any GUI app running on the local system (or, in the case of X11, any app which renders to the local X server, regardless of where the X client is running) can also read the clipboard more or less freely. If the user runs an app which steals the clipboard contents and uses them for nefarious purposes, we don't blame X or Wayland for allowing this. Running a local app inside of the terminal (such as SSH) should be no different.
3. SSH needs to do pty allocation etc., so it's already in the business of terminal emulation anyway. Adding OSC 52 filtering wouldn't be too much extra work.
4. SSH knows what host we're connected to. gnome-terminal probably doesn't.
5. This is how X11 forwarding has historically worked (consider -X vs. -Y). SSH is the security boundary, and the local terminal emulator is just responsible for rendering text to the screen.

Ubuntu 21.10 (Impish Indri) released

Posted Oct 17, 2021 19:29 UTC (Sun) by ibukanov (subscriber, #3942) [Link] (2 responses)

With not-so-trusted containers one may not use ssh to enter them. So a better solution will be a utility that can be used to wrap any command including ssh or container enter command. That utility then filters OSC 52 and do sensible things with copy-paste before forwarding data to the terminal application.

Ubuntu 21.10 (Impish Indri) released

Posted Oct 18, 2021 1:22 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (1 responses)

Sure, that works too. My main point is that the GUI terminal emulator is generally not a great place to put the security boundary, because whatever app runs inside of it already has the technical ability to read the clipboard anyway. If the user decides to run some application, and that app prints an OSC 52 code which steals the clipboard contents, then there are really only two cases here:

* The user is screwed anyway because they just executed malware. Malware can already steal your clipboard contents by other means, and do plenty of much nastier things besides.
* The app is trusted (not malware), but failed to implement an appropriate security boundary between the user and some untrusted system. Then this is a matter of the app's security model either being inadequate or not matching the user's desired security model. That's none of gnome-terminal's business.

We can argue until the cows come home about the proper way to implement this security boundary, but I think it's pretty clear that the answer is not "filter the codes out at the GUI terminal emulator on the local system."

Ubuntu 21.10 (Impish Indri) released

Posted Oct 18, 2021 6:31 UTC (Mon) by ibukanov (subscriber, #3942) [Link]

There is a reasonable way to implement OSC 52 in the terminal with rather minimal risk even in case of a malicious code running in the container. Allow copy-paste only when the terminal has focus and only within one second or less after a press on a physical key. For copy also require that content of the clipboard was pasted there within, say, 10 seconds after the last copy operation. Alternatively to copy the terminal emulator may require first to press a special keyboard shortcut to make the content of the keyboard available for OSC 52 access. The latter will be similar to how qube-os implements cut-and-paste between virtual machines.

Until such functionality is implemented in a terminal it is reasonable to implement it in a filtering application.

Ubuntu 21.10 (Impish Indri) released

Posted Oct 18, 2021 15:24 UTC (Mon) by foom (subscriber, #14868) [Link]

Firstly, SSH does not do terminal emulation. Adding terminal escape sequence filtering to SSH would be a major change.

Additionally, this is not simply an issue of SSH. There are numerous ways to get untrusted and unfiltered text printed to your terminal besides just ssh. E.g. "nc host", "cat file", "curl url", (or even "mpg123" per the GNOME issue linked earlier).

But, finally, your terminal emulator is indeed functioning as a security boundary these days. The expectation of (most) users is that printing arbitrary text to the terminal cannot materially affect the rest of the system, outside limited and well-defined aspects. (Clipboard access does seem like a reasonable candidate to be one of those, as long as it's under the user's control -- which is what the entire discussion on the gnome bug is about).

Historically, it was certainly not always the case that the terminal emulator authors considered the terminal emulator to be a security boundary (see, f.ex. the addition of the OSC 3 sequence to xterm back in 1999, which lets you set an arbitrary X property on the top-level xterm window!). There have been a variety of control sequences in xterm which had to be disabled in the intervening years, as part of that transition of expectations.

See e.g. these issues:
https://www.debian.org/security/2003/dsa-380 (remote command execution, via the combination of "set window title" followed by "get window title" printing the command back to a shell prompt.)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510030 (same, via a DECRQSS parse-error similarly printing back the input text -- plus a variety of other badness).

Fortunately when the OSC52 "get clipboard" sequence was invented, they decided to encode the contents with base64, which at least avoids the whole "remote command execution" set of issues.