Abusing url handling in iTerm2 and Hyper for code execution
vin01.github.io> 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.
I believe skopeo should allow you to: https://github.com/containers/skopeo
Slightly off-topic, but...
> Hyper is an Electron-based terminal
Why!?
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.
> I can't imagine using one written in Electron.
Ok but why?
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.
[0] https://github.com/coreutils/coreutils/blob/2a72cf1e9959f40b...
You don't need a "compromised app" if the escape codes are in a file you cat.
>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.
It is the first one, they need to be printed and clicked.
There is also another escape sequence, OSC 1337, apparently already implemented in iTerm2 [0], which makes iTerm2 open the URL instead of printing it:
[0] https://gitlab.com/gnachman/iterm2/-/issues/10994The 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.
It 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/fc9ae5c90f53cb1e...
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.
You never want to see raw, attacker-supplied text in a terminal, actually.
It 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 | bashYou know the rules, and so do I.
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.
Docker is at least sandboxed by default and requires sudo password to run commands.
There are advantages to docker, but also disadvantages. Definitely the same w/ "curl | sh" That's all I was trying to allude to, tongue in cheek.
But it requires sudo or effective-sudo to run any command, making such a measure worthless
I can't believe curl | sh is still the recommended way to install oh-my-zsh
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".
You can also throw in a `-x` at the end there.
> sophisticated enough to send different contents to a browser and to curl
Checking the Accept header (or User-Agent or a bunch of other things) is very difficult :)
GP likely meant differentiating `curl` and `curl | bash`.
https://web.archive.org/web/20240520142212/https://www.idont...
Did they? IDK, just differentiating browser from curl is incredibly likely to be "good enough" as an attacker.
I did have that attack in mind, yes.
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://
I like it because you can replace sh with whatever you want to go over the script
I 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.
Is 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?
`| less`
Think you can see the full url one mouse over in some terminals (and rebind what clicks do to disable opening)
I stopped using iTerm2 as soon as I learned it will open arbitrary URLs.
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.
I enabled it because github's "turn this push into a PR" link is such a timesaver.
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 =)
It will only open the URLs after presenting a confirmation banner that says: "open this URL? http://example.com/", or if you command-click on a link.
At the very end of the article,
> Upgrade to iTerm2 3.5.0
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]
Features of iTerm2 I use:
- fullscreen without using MacOS's spaces implementation of fullscreen
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.
Give wezterm a try: https://wezfurlong.org/wezterm/index.html
It is cross OS (learn once and use the same terminal in Windows, macOS and Linux), actively developed and written in rust
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].
1. https://blog.mozilla.org/security/2019/10/09/iterm2-critical...
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?
The only reason I use iterm is so I have tmux integration and can scroll my tmux windows. That is the killer feature for me.
people talked about this elsewhere, the AI part is fully optional and disabled by default
> I would like very much to get off this ride
What's keeping you? It sounds like you want a much more lightweight terminal emulator that iTerm, which is totally fair, and I bet that exists!
If you don't want the terminal to have any features then why don't you just use the default Terminal app?
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.
MacOS has terrible window management by default. Having one window with multiple panes helps a lot.
You could use screen or tmux of course, but they have a more steep learning curve.
Terminal.app seems in no hurry to add truecolor support, which is really nice for editor color schemes and other things once you’ve gotten used to it.
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).