How on Earth did something like this become the norm?
I don't work with software like most here, but just opening the Cargo.lock file sets off an alarm in my brain.
After seeing how much stuff was pulled when I once installed a couple programs with cargo, I added it to the "don't touch a project if it's made with this language" pile, alongside NIM and Python (though Python I can't quite avoid).
Sure, the decision to "offload" some components is understandable, and sometimes preferred (crypto libs, etc). We're not all masters of every field.
But if you do it 200+ times I'll question what you're even trying to do.
I use non-Unicode terminal mode (I might prefer to use a terminal emulator that does not support Unicode but you can add fonts for arbitrary character sets (of your choice, so that none are forced) instead) and program the browser to always display URLs as ASCII. So, when I copy the text to the terminal, I get "#" in place of the Cyrillic alphabets.
I think making IDN work the way it does was a mistake. I thought of making IDN with a character set specific for that use (I did think about how it would work) instead of using Unicode or any other existing character sets (none of them are suitable, as far as I am concerned; however, this new IDN character set would potentially be suitable for some other uses such as perhaps package names). Using one character set for everything is not very good, and Unicode is especially bad for this. (Although in my opinion, TRON code is generally better than Unicode, neither TRON code nor Unicode is the one to use for this)
However, there are other problems with paste in the terminal window, but bracketed paste mode can mitigate some of these problems in some cases, it is not entirely helpful.
A simpler solution: examine the URL displayed in the browser window before copying terminal commands from the page. E.g. "starts with github.com" -> "trusted GitHub UI indicates the repo is the official one for this project" -> "URL points to the official project README" -> "terminal commands are most likely not malicious, and if they are, there's a bigger problem here".
Of course, more secure installation methods should be preferred, but those are not always available. I am simply comparing the provided solution to homograph attacks with another solution to the same problem.
The word tirith means guard (or watch) in Sindarin, one of Tolkien's languages from Lord of the Rings. See also Minas Tirith! I really enjoy this utility's name.
CP437 (the PC character set) has three blank spaces (although 0x00 is probably not going to be used), so 0xFF is displayed same as 0x20 so there is still a homoglyph.
This looks to be a very specific tool to check URLs on the command line. Terminal emulators don't care about that. Even shells running in those terminal emulators don't care about those specifics because why would they. One could easily want to do something with a funny url like that that doesn't involve content fetching etc.
If you can disable Unicode in your terminal emulator, then it will be. (Unfortunately, that won't help if you want Unicode in your terminal emulator, though.)
I'm not holding it as a best practice, and I don't see how that was interpreted from my comment. I think installation through a copy/pasted script is terrible business.
But it was held as something exceptional, when here in reality a number of extremely widely used products, frameworks and tools provide installation through a curled shell script command.
Another example is CUDA on Linux. Installed via some copy/pasted scripts from a webpage.
While true, then I'd just skip installing these products and find another way. And if this is the only way and the product is important (say, brew), make an exception.
As a child in the 1980s we'd go for long walks in the woods. One time a friend brought a pair of 30 inch bolt cutters with him, you know, as a personality extension. And of course, there was some dubious reason to use them, and he was a hero for being over-provisioned.
A solution like this is those bolt cutters - I can admire it, but the odds I'm out on a walk with it, is very, very low.
Now if you work in a bolt factory, sure, this can run on every laptop, every user account, every environment.
But I'd hope my edge firewalls are L7 scanning for cyrillic 'i' in my domains cause otherwise I'm just gonna connect and get myself hacked.
Also there's always the risk that the bolt cutter has a defect (perhaps deliberately introduced at some point when it was manufactured) which will cause you more damage than the thing you're trying to prevent by carrying it.
I'm personally a bit wary of introducing a relatively obscure security tool into my setup, to protect against a rare possible attack. The chance that I'll get caught copy-pasting a compromised URL into my terminal is fairly small, and there's also a small chance I'll compromise my system either now or at some later point via a supply chain attack if I use the tool. Which chance is bigger?
It's about as safe as trusting all the add-ons in your IDE, and all the packages your node app pulls from random package repos.
It's just the plausible blame that shifts.
If you read the script before you pipe it into your shell, it's safe.
And if that's not safe, then it's just as dangerous to trust that an unopened bottle of ketchup is safe.
Nothing is safe. Everything is a judgement. Being culpable is a professional service. Lucky people out-earn unlucky people. The world is a scary place.
No, not really. This reads like ornate hand waving to distract from different threat models and situations.
A lot of safety is down to accountability. A distribution through an attributable marketplace or being verifiably signed.
Safety isn't a performative action, so reading a script may still confuse you or you may miss subtleties. But opting for a safer install mechanism makes a huge difference, which is we always ought to prefer apt, dnf, over the likes of curlbash, brew, npm.
I'm Not sure that I agree that it is automatically safer to prefer apt or dnf, and I'm definitely sure that it is not safer to prefer npm.
Safety is about managing risk. One element of managing risk is evaluating trust. I'm thinking that there are much fewer people I have to trust by copying the curl | bash install method from homebrew's secure website.
But at any rate, I completely agree that piping a curl'd script directly to the shell should be considered unsafe, even if it's from a trusted source. It's quite easy to do additional checks to reduce your risk significantly for this type of attack. You could read the contents of your clipboard with a hex editor and check for non-ascii characters. But wait? How do I install the hex editor? Don't I need a hex editor to check the install method of the hex editor? AAAAH! It's turtles all the way down!!!!
> If you read the script before you pipe it into your shell, it's safe.
If you download it first before executing it (instead of downloading it a second time when executing it), then that mitigates one problem, but still not all of them (like you mention). Other mitigations are also possible, such as hashing, certificate pinning, sandboxing, etc.
This is a good point. Made me think about how I will usually read if first, but in the browser. And it's easy for the server to check the user agent, and serve me a different version in the browser!
If you read the script before piping it into your shell, you're doing better than (I'm guessing) 90% of people, but it's still possible that the attacker who got you to copy https://xn--nstall-ovf.xn--example-cl-62i.dev into your terminal has also made similarly-hard-to-spot changes to the install script. E.g. if it downloads a .deb package from https://xn--nstall-ovf.xn--example-cl-62i.dev (same Cyrillic і character in there that looks like a Latin i but isn't), you might not spot that by reading the script.
But IMHO, your "unopened bottle of ketchup" analogy doesn't work. These days, the likelihood of someone trying to trick you into running arbitrary code disguised as an install script is so much higher than the chance that someone working at the ketchup bottling plant is deliberately contaminating bottles before they go out.
This is why we have linux distributions with maintainers who can take at least a basic look at the software, vet dependencies and run it through a test suite. And they only have to do that once for each new version and not again and again for each download.
Linux distributions contain a curated set of packages. And, if any, distros like Guix can import NPM crap and at least place it under an isolated container for work so the rest it's unharmed.
also you're getting at least some of crowd safety in it. If you're using Debian Testing or a rolling distro your package was probably tested by a bunch of people already.
If you're using stable/LTS branch, there were far more eyes on it too
And packages are signed, can't just hijack web domain to inject code
I would rather check urls with the following method:
instead of putting my trust in the hundreds of crates in this tool's Cargo.lock not having a supply chain attack.How on Earth did something like this become the norm? I don't work with software like most here, but just opening the Cargo.lock file sets off an alarm in my brain.
After seeing how much stuff was pulled when I once installed a couple programs with cargo, I added it to the "don't touch a project if it's made with this language" pile, alongside NIM and Python (though Python I can't quite avoid).
Go write a floating point package, by yourself (no AI assistance), from scratch. Then you will understand.
Sure, the decision to "offload" some components is understandable, and sometimes preferred (crypto libs, etc). We're not all masters of every field. But if you do it 200+ times I'll question what you're even trying to do.
I use non-Unicode terminal mode (I might prefer to use a terminal emulator that does not support Unicode but you can add fonts for arbitrary character sets (of your choice, so that none are forced) instead) and program the browser to always display URLs as ASCII. So, when I copy the text to the terminal, I get "#" in place of the Cyrillic alphabets.
I think making IDN work the way it does was a mistake. I thought of making IDN with a character set specific for that use (I did think about how it would work) instead of using Unicode or any other existing character sets (none of them are suitable, as far as I am concerned; however, this new IDN character set would potentially be suitable for some other uses such as perhaps package names). Using one character set for everything is not very good, and Unicode is especially bad for this. (Although in my opinion, TRON code is generally better than Unicode, neither TRON code nor Unicode is the one to use for this)
However, there are other problems with paste in the terminal window, but bracketed paste mode can mitigate some of these problems in some cases, it is not entirely helpful.
My terminal "warns" about them thanks to using a bitmap font that has no (significant?) Unicode coverage beyond code points 0 to 255.
A simpler solution: examine the URL displayed in the browser window before copying terminal commands from the page. E.g. "starts with github.com" -> "trusted GitHub UI indicates the repo is the official one for this project" -> "URL points to the official project README" -> "terminal commands are most likely not malicious, and if they are, there's a bigger problem here".
Of course, more secure installation methods should be preferred, but those are not always available. I am simply comparing the provided solution to homograph attacks with another solution to the same problem.
The word tirith means guard (or watch) in Sindarin, one of Tolkien's languages from Lord of the Rings. See also Minas Tirith! I really enjoy this utility's name.
My terminal is set to CP437 and uses a font incapable of rendering anything else.
Then again, I don't blindly pipe directly from the network into the shell either.
CP437 (the PC character set) has three blank spaces (although 0x00 is probably not going to be used), so 0xFF is displayed same as 0x20 so there is still a homoglyph.
Weird that just 3 days ago https://github.com/makalin/preexec was released with almost exactly the same functionality written in Go.
Amusing that the chosen illustrative homograph is "i" and tirith has two...
Handy! I feel like this should be built into the terminal emulator though?
This looks to be a very specific tool to check URLs on the command line. Terminal emulators don't care about that. Even shells running in those terminal emulators don't care about those specifics because why would they. One could easily want to do something with a funny url like that that doesn't involve content fetching etc.
If you can disable Unicode in your terminal emulator, then it will be. (Unfortunately, that won't help if you want Unicode in your terminal emulator, though.)
If you're copying curl|sh from webpages you're already not paying attention and domain doesn't matter
It is literally the method given to install a number of products. The first mechanism given as a fix, of sorts, is to install something via brew.
Brew is installed by copying a command line-
https://brew.sh
I mean, I guess you could retype it, but there is no intention for anyone to do that.
I think Homebrew still makes a mess with permissions on multiuser systems (at least on macOS), so it's probably not a good example of best practices.
I'm not holding it as a best practice, and I don't see how that was interpreted from my comment. I think installation through a copy/pasted script is terrible business.
But it was held as something exceptional, when here in reality a number of extremely widely used products, frameworks and tools provide installation through a curled shell script command.
Another example is CUDA on Linux. Installed via some copy/pasted scripts from a webpage.
I have must misunderstood or misinterpreted your comment a bit then.
I fully agree, this seems to be becoming more and more common unfortunately.
While true, then I'd just skip installing these products and find another way. And if this is the only way and the product is important (say, brew), make an exception.
This is an incredible tool.
As a child in the 1980s we'd go for long walks in the woods. One time a friend brought a pair of 30 inch bolt cutters with him, you know, as a personality extension. And of course, there was some dubious reason to use them, and he was a hero for being over-provisioned.
A solution like this is those bolt cutters - I can admire it, but the odds I'm out on a walk with it, is very, very low.
Now if you work in a bolt factory, sure, this can run on every laptop, every user account, every environment.
But I'd hope my edge firewalls are L7 scanning for cyrillic 'i' in my domains cause otherwise I'm just gonna connect and get myself hacked.
Also there's always the risk that the bolt cutter has a defect (perhaps deliberately introduced at some point when it was manufactured) which will cause you more damage than the thing you're trying to prevent by carrying it.
I'm personally a bit wary of introducing a relatively obscure security tool into my setup, to protect against a rare possible attack. The chance that I'll get caught copy-pasting a compromised URL into my terminal is fairly small, and there's also a small chance I'll compromise my system either now or at some later point via a supply chain attack if I use the tool. Which chance is bigger?
or just don't pipe random webpages into shell.
a pre exec handler for your shell gives somebody a lot of power. if this gets sufficiently popular, pwning this brew package can get one faar...
> curl -sSL https://install.example-cli.dev | bash # safe
This is not and has never been safe.
It's about as safe as trusting all the add-ons in your IDE, and all the packages your node app pulls from random package repos.
It's just the plausible blame that shifts.
If you read the script before you pipe it into your shell, it's safe.
And if that's not safe, then it's just as dangerous to trust that an unopened bottle of ketchup is safe.
Nothing is safe. Everything is a judgement. Being culpable is a professional service. Lucky people out-earn unlucky people. The world is a scary place.
No, not really. This reads like ornate hand waving to distract from different threat models and situations.
A lot of safety is down to accountability. A distribution through an attributable marketplace or being verifiably signed.
Safety isn't a performative action, so reading a script may still confuse you or you may miss subtleties. But opting for a safer install mechanism makes a huge difference, which is we always ought to prefer apt, dnf, over the likes of curlbash, brew, npm.
I'm Not sure that I agree that it is automatically safer to prefer apt or dnf, and I'm definitely sure that it is not safer to prefer npm.
Safety is about managing risk. One element of managing risk is evaluating trust. I'm thinking that there are much fewer people I have to trust by copying the curl | bash install method from homebrew's secure website.
But at any rate, I completely agree that piping a curl'd script directly to the shell should be considered unsafe, even if it's from a trusted source. It's quite easy to do additional checks to reduce your risk significantly for this type of attack. You could read the contents of your clipboard with a hex editor and check for non-ascii characters. But wait? How do I install the hex editor? Don't I need a hex editor to check the install method of the hex editor? AAAAH! It's turtles all the way down!!!!
> If you read the script before you pipe it into your shell, it's safe.
This isn't strictly true. It's possible to detect on the server side if curl is being piped and deliver different content: https://web.archive.org/web/20241224173203/https://www.idont...
> If you read the script before you pipe it into your shell, it's safe.
If you download it first before executing it (instead of downloading it a second time when executing it), then that mitigates one problem, but still not all of them (like you mention). Other mitigations are also possible, such as hashing, certificate pinning, sandboxing, etc.
This is a good point. Made me think about how I will usually read if first, but in the browser. And it's easy for the server to check the user agent, and serve me a different version in the browser!
Yup. The script that you execute should literally be the one that you read. (I.e, no downloading twice)
If you read the script before piping it into your shell, you're doing better than (I'm guessing) 90% of people, but it's still possible that the attacker who got you to copy https://xn--nstall-ovf.xn--example-cl-62i.dev into your terminal has also made similarly-hard-to-spot changes to the install script. E.g. if it downloads a .deb package from https://xn--nstall-ovf.xn--example-cl-62i.dev (same Cyrillic і character in there that looks like a Latin i but isn't), you might not spot that by reading the script.
But IMHO, your "unopened bottle of ketchup" analogy doesn't work. These days, the likelihood of someone trying to trick you into running arbitrary code disguised as an install script is so much higher than the chance that someone working at the ketchup bottling plant is deliberately contaminating bottles before they go out.
Hah. Hacker News is immune to homograph attacks. Good to know.
> 2017-04-14: Blake Rand
> Links in comments were vulnerable to an IDN homograph attack.
https://news.ycombinator.com/security.html
> It's about as safe as trusting all the add-ons in your IDE, and all the packages your node app pulls from random package repos.
Absolutely incorrect. You can do far easier due dilligence for IDE plugins
Can you elaborate? How do you like to evaluate your IDE plugins?
This is why we have linux distributions with maintainers who can take at least a basic look at the software, vet dependencies and run it through a test suite. And they only have to do that once for each new version and not again and again for each download.
Linux distributions contain a curated set of packages. And, if any, distros like Guix can import NPM crap and at least place it under an isolated container for work so the rest it's unharmed.
also you're getting at least some of crowd safety in it. If you're using Debian Testing or a rolling distro your package was probably tested by a bunch of people already.
If you're using stable/LTS branch, there were far more eyes on it too
And packages are signed, can't just hijack web domain to inject code
it really irks me that this is the default way to install micromamba
https://mamba.readthedocs.io/en/latest/installation/micromam...