> This is of course a harmless PoC and you can try it out using docker pull vin01/escape-seq-test:latest --platform darwin/arm64 or docker run --rm vin01/escape-seq-test and you should see the injected link as shown below.
Wow, I wouldn't have expected `docker pull` in particular to allow arbitrary content injection. Does anyone know of any tools which scan images being pulled before passing them over to `docker` for processing?
> I wouldn't have expected `docker pull` in particular to allow arbitrary content injection.
Having read Docker source code and seen a repetitive pattern of silly mistakes with dire consequences, I emphatically would expect it to have such, and many other similar, issues.
My personal favorite is still the time they computed a hash of a download, but then failed to compare it to anything.
Electron beatings will continue for as long as making a proper GUI for major platforms requires learning three different languages and four different UI toolkits, where every one of them is less flexible and harder to use than the web stack.
For developers Electron is the easiest way to have a portable UI, with very flexible and capable styling, decent text rendering, animations, and a layout and rendering engine optimized for a very broad range of use-cases, with fantastic developer tools.
I get that tradeoff, and I can see how it makes sense for apps that don't interface that much with the OS/UI they run on (although I'm still not a fan of the resource usage and the occasional UI yankiness).
But for a terminal emulator? These are pretty deeply integrated with the OS they run on and often run with elevated permissions and/or get to pass through passwords as they're entered! I can't imagine using one written in Electron.
Would it help if SSH clients don't pass TERM variable to identify that current terminal is capable of handling "\e]8" ? I assume TERM is how the remote application know that this exploit is available.
I also assume that this vulnerability is meant for remote apps accessed via SSH or similar, since a compromised app that is executed locally probably have easier exploits (they might just run calculator or whatever directly without going through escape sequences, for example).
AFAIK, the remote applications simply do an isatty() check on the stdout and that's it; a proper terminal is then apparently expected to correctly skip and quietly ignore any OSC sequence it does not understand. See the source of ls [0], for example.
>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.
There 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.
The 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.
iTerm2 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.
I 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.
Getting it out of a repository wouldn't make any more vetting appear as if by magic.
And if you're facing an attacker sophisticated enough to send different contents to a browser and to curl, then you're probably not going to find their backdoor in the first place. And it would be stupid of them to depend on that trick, so this becomes an extremely niche case not worth worrying about.
And multiply that sophistication by a hundred times because this is on github servers.
The "what if the file is truncated" issue is the only realistic one, and competent installers like this one define functions and don't run them until the last line.
> Getting it out of a repository wouldn't make any more vetting appear as if by magic.
But it makes it way easier to figure out what happened if you do get attacked.
With "curl | sh" if a compromised site only sends the attack code randomly and I get unlucky I won't have a copy of the attack code afterwards. If I go to the site to grab a copy I'll probably get a copy without the attack code.
With "curl > /tmp/foo.$$; sh < /tmp/foo.$$" if I am unlucky and get the attack code I can at least look at /tmp/foo.$$ to see what happened, and download the code again and see if it is the same.
If you insist on piping, at least do "curl | tee /tmp/foo.$$ | sh".
But honestly it doesn't take a lot of sophistication to hide an exploit somewhere in an entire piece of software. The average person is very vulnerable to a malicious dev and the way they download is very unlikely to matter as long as it's not http://
> 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.
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?
Huh, I just disabled it in Preferences and kept on rolling. This is the other viable option: Settings->Pointer->General and disable cmd-click opens filename/URL.
Yeah, that would be convenient. It feels like users do get the power to choose utility (enable) vs skeeved out (disable), which is all you can ask for =)
I had just gotten the upgrade notification for 3.5.0 a few minutes ago. I scrolled through the release notes a bit and got to the "AI" section and I would like very much to get off this ride. I am grumpy and a terminal should be a terminal.
Features of iTerm2 I don't use and don't think belong in a terminal emulator:
- tmux integration
- shell integration
- ssh integration
- password manager integration
- hooks
- syntax highlighting *that's baked into the terminal*
- installing its own python runtimes (?!)
- ~blindly~ opening URLs when rendering a certain escape sequence [0]
- fullscreen without using MacOS's spaces implementation of fullscreen
.... This got away from me and went from grumpy muttering to a snarky rant. I like iTerm2, it's just starting to feel like somebody else's terminal, that's all.
Edit: tried to cross out "blindly" above, it does ask you whether you want to open the URL, though it offers to always allow it for that host which seems like it might be iffy, but at least if I never click "always allow", I'll be notified if anything tries to inject this OSC sequence.
While it is nice to have options, I still think iTerm2 is one of the best terminal emulators for OS X out there. It has also most likely been audited more thoroughly than newer options out there. There was a security audit sponsored by Mozilla in 2019 [1].
Written in Rust is nice, but it also uses `libssh` which has a history of security issues and bad support for recent ciphers. Would be interesting if it also has issues with terminal escape sequences.
I'm not sure I want any features in my terminal at this point...
I had major slow down in wexterm on my MBA. I didn't really look into it because the terminal is something I want to install and forget about, so the solution may be trivial. But it was so laggy as to be unusable.
It's a bit heavy, but I've liked Tabby outside Windows a bit... I really like the new Windows terminal from MS, but it's Windows only, Tabby is about the closest I've found to it.
Just to double-check: you know that option-clicking on the green fullscreen icon does something close to fullscreen-without-spaces-implementation right?
Honestly I never understood the need to replace macOS Terminal. I'm heavy terminal user, that's my most used application by far. But macOS Terminal is absolutely fine for my needs and I never felt the need for any additional features.
Huh? Typing passwords would be a nice feature, nicer than the myriad of other ancient teletype control codes. Something like ^p (type password) ^P (return to terminal).
Wow, I wouldn't have expected `docker pull` in particular to allow arbitrary content injection. Does anyone know of any tools which scan images being pulled before passing them over to `docker` for processing?