Abusing url handling in iTerm2 and Hyper for code execution(vin01.github.io) |
Abusing url handling in iTerm2 and Hyper for code execution(vin01.github.io) |
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?
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.
> Hyper is an Electron-based terminal
Why!?
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.
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 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).
[0] https://github.com/coreutils/coreutils/blob/2a72cf1e9959f40b...
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.
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.
curl -s -L https://raw.githubusercontent.com/Groxx/rickrollrc/master/roll.sh | bashSure, 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?
> 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.
It is cross OS (learn once and use the same terminal in Windows, macOS and Linux), actively developed and written in rust
1. https://blog.mozilla.org/security/2019/10/09/iterm2-critical...
I'm not sure I want any features in my terminal at this point...
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!
You could use screen or tmux of course, but they have a more steep learning curve.
Ok but why?
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.
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.
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".
Checking the Accept header (or User-Agent or a bunch of other things) is very difficult :)
> 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.
https://web.archive.org/web/20240520142212/https://www.idont...
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://