Hacker News Reader

Comment by Groxx | Hacker News Reader

>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.

View on HN

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:

    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

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.

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...

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 | bash

You 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.

But it requires sudo or effective-sudo to run any command, making such a measure worthless

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.

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.

> 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://

> 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.

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)

Reply on news.ycombinator.com