3 ms·

You should always paste into an editor first, just copying any text from a webpage is a risk. There are even examples using terminal escape codes, to hide what

by b112 3y ago

You should always paste into an editor first, just copying any text from a webpage is a risk. There are even examples using terminal escape codes, to hide what happened. https://www.reddit.com/r/privacy/comments/rv964x/comment/hr4z1fv/?utm_source=share&utm_medium=web2x&context=3 https://www.reddit.com/r/privacy/comments/rv964x/comment/hr4...

LinuxBender 3y ago
Adding to the demo here is one using CSS [1] [1] - https://thejh.net/misc/website-terminal-copy-paste https://thejh.net/misc/website-terminal-copy-paste
gwnywg 3y ago
I thought the bug is that you don't need to interact with FF to get injection into pasted payload... So am I wrong to think that as long as FF runs in the background, you can still get injection to the payload you just copied from the editor?
Krasnol 3y ago
I paste into address bar to remove formatting etc.
marbu 3y ago
Using terminal which can detect control characters in a pasted text will (partially) help here as well. Eg.: rxvt-unicode has confirm-paste plugin: https://wiki.archlinux.org/title/rxvt-unicode#Confirm_paste https://wiki.archlinux.org/title/rxvt-unicode#Confirm_paste
omoikane 3y ago
The bug here is that between the "copy" and "paste" operations, a script running in the background can win the race to rewrite clipboard contents before "paste" happens. Thus the defense needs to happen on the "paste" side, changing the "copy" side would result in the same race. A solution is bracketed paste[1] as mentioned in earlier comments[2], which would allow the user to examine a pasted command before running it. [1] https://en.wikipedia.org/wiki/Bracketed-paste https://en.wikipedia.org/wiki/Bracketed-paste [2] https://news.ycombinator.com/item?id=37966924 https://news.ycombinator.com/item?id=37966924
hollerith 3y ago
>You should always paste into an editor first and that editor should not be running "inside" a terminal -- or rather I don't understand why those that like interacting with their editor via a terminal interface don't create a new protocol that doesn't have the warts and vulnerabilities the current ancient protocol has.
- arp242 3y ago
  Compatibility, basically. e.g. Vim creating their own protocol is rather pointless if no terminal implements it, and some terminal creating their own protocol is also rather pointless without application support. Plus there's tons of software out there and it'll take a long time for it all to be rewritten, if that ever happens. e.g. X11 will still be around for a long time as well. So you will need to remain compatible with the current protocol even if you invent something new and better, and in that sense it doesn't really fix anything., at least not right now. It might fix stuff 15 years down the line, maybe, but in-between now and 15 years everything will be more complex by having two protocols. And all things considered, it's not that bad, IMHO. There's the KiTTY Keyboard protocol to solve some obvious UX issues with keyboard handling, which is a clear improvement and motivation, whereas some exploit vectors that don't really see live exploits isn't really.
  - hollerith 3y ago
    There are dozens of toolkits for authoring GUIs, which are much more complicated than the protocol we are talking about and consequently much more work, so, no I don't see why the Vim project cannot take on the work of defining a new protocol and maintaining a client that speaks the protocol. The hairiest Emacs Lisp code I know about is the code for responding to mouse actions, e.g., clicking and dragging, and most Vim users don't even want to use a pointing device to interact with Vim IIUC. (In contrast, 80% of Emacs users who responded to a survey do not interact with Emacs through a terminal interface.) For example, the old scripting language Tcl has its own GUI toolkit named Tk that has a pretty good reputation. >And all things considered, it's not that bad It seems bad enough to me to be worth re-architecting.
_flux 3y ago
My Tilix/zsh combination just pastes the content as a multi-line entry to the terminal. If the clipboard contains control codes (e.g. arrow up) they are entered verbatim (as if I had used the quoting function ^V to enter them). So I suppose we're not very far from this not being a problem in general. Though I understand this also works via control codes. I hope Tilix is smart enough to filter them out from the clipboard before doing this.. edit: I tested that case out, and it works. I suppose the protocol uses quoting.
- dgl 3y ago
  See my reply in the thread: https://www.openwall.com/lists/oss-security/2023/10/20/2 https://www.openwall.com/lists/oss-security/2023/10/20/2 — not all terminals get this right.

by b112 3y ago

LinuxBender 3y ago

Adding to the demo here is one using CSS [1] [1] - https://thejh.net/misc/website-terminal-copy-paste https://thejh.net/misc/website-terminal-copy-paste

gwnywg 3y ago

I thought the bug is that you don't need to interact with FF to get injection into pasted payload... So am I wrong to think that as long as FF runs in the background, you can still get injection to the payload you just copied from the editor?

Krasnol 3y ago

I paste into address bar to remove formatting etc.

marbu 3y ago

Using terminal which can detect control characters in a pasted text will (partially) help here as well. Eg.: rxvt-unicode has confirm-paste plugin: https://wiki.archlinux.org/title/rxvt-unicode#Confirm_paste https://wiki.archlinux.org/title/rxvt-unicode#Confirm_paste

omoikane 3y ago

The bug here is that between the "copy" and "paste" operations, a script running in the background can win the race to rewrite clipboard contents before "paste" happens. Thus the defense needs to happen on the "paste" side, changing the "copy" side would result in the same race. A solution is bracketed paste[1] as mentioned in earlier comments[2], which would allow the user to examine a pasted command before running it. [1] https://en.wikipedia.org/wiki/Bracketed-paste https://en.wikipedia.org/wiki/Bracketed-paste [2] https://news.ycombinator.com/item?id=37966924 https://news.ycombinator.com/item?id=37966924

hollerith 3y ago

>You should always paste into an editor first and that editor should not be running "inside" a terminal -- or rather I don't understand why those that like interacting with their editor via a terminal interface don't create a new protocol that doesn't have the warts and vulnerabilities the current ancient protocol has.

arp242 3y ago
Compatibility, basically. e.g. Vim creating their own protocol is rather pointless if no terminal implements it, and some terminal creating their own protocol is also rather pointless without application support. Plus there's tons of software out there and it'll take a long time for it all to be rewritten, if that ever happens. e.g. X11 will still be around for a long time as well. So you will need to remain compatible with the current protocol even if you invent something new and better, and in that sense it doesn't really fix anything., at least not right now. It might fix stuff 15 years down the line, maybe, but in-between now and 15 years everything will be more complex by having two protocols. And all things considered, it's not that bad, IMHO. There's the KiTTY Keyboard protocol to solve some obvious UX issues with keyboard handling, which is a clear improvement and motivation, whereas some exploit vectors that don't really see live exploits isn't really.
- hollerith 3y ago
  There are dozens of toolkits for authoring GUIs, which are much more complicated than the protocol we are talking about and consequently much more work, so, no I don't see why the Vim project cannot take on the work of defining a new protocol and maintaining a client that speaks the protocol. The hairiest Emacs Lisp code I know about is the code for responding to mouse actions, e.g., clicking and dragging, and most Vim users don't even want to use a pointing device to interact with Vim IIUC. (In contrast, 80% of Emacs users who responded to a survey do not interact with Emacs through a terminal interface.) For example, the old scripting language Tcl has its own GUI toolkit named Tk that has a pretty good reputation. >And all things considered, it's not that bad It seems bad enough to me to be worth re-architecting.

_flux 3y ago

My Tilix/zsh combination just pastes the content as a multi-line entry to the terminal. If the clipboard contains control codes (e.g. arrow up) they are entered verbatim (as if I had used the quoting function ^V to enter them). So I suppose we're not very far from this not being a problem in general. Though I understand this also works via control codes. I hope Tilix is smart enough to filter them out from the clipboard before doing this.. edit: I tested that case out, and it works. I suppose the protocol uses quoting.

dgl 3y ago
See my reply in the thread: https://www.openwall.com/lists/oss-security/2023/10/20/2 https://www.openwall.com/lists/oss-security/2023/10/20/2 — not all terminals get this right.