5 ms·
>Any links using those schemes when clicked, would open the MacOS terminal to perform the corresponding action. I'm unclear which of these are being described:
by Groxx 2y ago
>Any links using those schemes when clicked, would open the MacOS terminal to perform the corresponding action.
I'm unclear which of these are being described:
1: when printed and clicked, they may be handled by the terminal, and the terminal's handling allows more behaviors than it should, allowing code execution
2: when printed, these urls are automatically executed by the shell, allowing code execution
Neither are good of course, but they're different levels of badness, and I feel like I must be missing a single critical word somewhere to be able to figure out which it is.
---
That said, oh boy I do not want this:
>Most terminal emulators these days allow using Osc 8 to directly generate hyperlinks from arbitrary text.
Is there a standard way to disable it? That sounds awful, terminals don't have even a small fraction of browsers' malicious-link-defense mechanisms (as demonstrated). I always want to see the full url in a terminal.
- vin10 2y agoIt is the first one, they need to be printed and clicked.
- Joker_vD 2y agoThere is also another escape sequence, OSC 1337, apparently already implemented in iTerm2 [0], which makes iTerm2 open the URL instead of printing it: The hypothetical new control code is different because it does not display a hyperlink; it directly opens the link using the appropriate system URL handler. [0] https://gitlab.com/gnachman/iterm2/-/issues/10994 https://gitlab.com/gnachman/iterm2/-/issues/10994
- lmz 2y agoThe commit linked there checks host only and not protocol for "always allow". I wonder if that's going to be a problem with some of the more interesting protocols.
- xvector 2y agoiTerm2 has definitely not been designed with security in mind. It has a massive and rapidly growing attack surface and quite a bit of feature bloat (literally hundreds of "features") - I would not recommend using it over Terminal for anyone security minded.
- vin10 2y agoIt is guarded by a warning and requires explicit approval similar to browsers but yes, it does broaden the attack surface: https://gitlab.com/gnachman/iterm2/-/commit/fc9ae5c90f53cb1ed54d338a3bf1e09f22d22894#c7949d378a5b9fa837d1322ccfded21fa5e97bc4_565_578 https://gitlab.com/gnachman/iterm2/-/commit/fc9ae5c90f53cb1e...
- Repulsion9513 2y agoYou never want to see raw, attacker-supplied text in a terminal, actually.
- lxgr 2y agoIs that realistic? Sure, text editors and viewers like vim or less can probably filter out terminal escape sequences, but should arbitrary programs printing (potentially user-supplied) strings to stdout have to? Maybe terminal escape sequence processing should be opt-in (on a by-process/job level) rather than opt-out?
- Repulsion9513 2y ago`| less`
- Groxx 2y agoIt sure is a good thing we never run anything in our terminals without fully vetting all output. curl -s -L https://raw.githubusercontent.com/Groxx/rickrollrc/master/roll.sh | bash
- Repulsion9513 2y agoI mean, the context I was replying to was: > terminals don't have even a small fraction of browsers' malicious-link-defense mechanisms (as demonstrated). I always want to see the full url in a terminal. And yeah you're right if you're just piping stuff to bash, malicious URLs are the least of your worries, but that doesn't change the fact that outputting data (that may contain raw control codes) to your terminal is dangerous with or without linkified-URLs.
- labster 2y agoYou know the rules, and so do I.
- dv_dt 2y agoI know I prefer my exploits to come from opaque corners of package formats or docker layers as bofh intended. The more indirect handoffs of trust the merrier.
- eviks 2y agoThink you can see the full url one mouse over in some terminals (and rebind what clicks do to disable opening)