Yes, this is the correct approach from a security perspective.

No, it is different, as it adds an entire layer of indirection and unknown to the mix, increasing the risk in the process.

It is, see https://github.com/m4tx/curl-bash-attack

Oh that is clever.

Not sure how else to explain this. Look at the CISA bulletin on Shai-Hulud the attacker published valid and signed binaries that were installed by hundreds of users.

"CISA is releasing this Alert to provide guidance in response to a widespread software supply chain compromise involving the world’s largest JavaScript registry, npmjs.com. A self-replicating worm—publicly known as “Shai-Hulud”—has compromised over 500 packages.[i]

After gaining initial access, the malicious cyber actor deployed malware that scanned the environment for sensitive credentials. The cyber actor then targeted GitHub Personal Access Tokens (PATs) and application programming interface (API) keys for cloud services, including Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure.[ii]

The malware then:

• Exfiltrated the harvested credentials to an endpoint controlled by the actor.
• Uploaded the credentials to a public repository named Shai-Hulud via the GitHub/user/repos API.
• Leveraged an automated process to rapidly spread by authenticating to the npm registry as the compromised developer, injecting code into other packages, and publishing compromised versions to the registry.[iii]"

That's an interesting proof of concept, but I don't think it shows it's different. That's a server side attack, whoever has control of the server could just have the script download a malicious binary instead and you wouldn't be able to tell from the script.

After gaining initial access, the malicious cyber actor deployed malware that scanned the environment for sensitive credentials.

So as I said, the keys got compromised. Thats what i said in the second post.

This helped a lot. I had no clue I could post the curl string in the URL bar of a browser to view the script. Thanks for the education!

Never have I ever piped curl to bash.

I never thought about opening it in a browser. I always used curl to download such a script and view it where it was supposed to be run.

What you said is the key infra needs to get compromise. I do not need to own the PKI that issued the certs, I just need the private key of the signer. And again, this is something that happens. A lot. A software publisher gets owned, then their account is used to distribute malware.

You didn't knew that the tool to handle URLs written in C (very creatively named C-Url) was handling URLs? It's also written in C if you didn't knew.

But those are two very different things, I can very easily give you a one liner using curl|bash that will compromise your system, to get the same level of compromise through a proper authenticated channel such as apt/pacman/etc you would need to compromise either their private keys and attack before they notice and change them or stick malicious code in an official package, either of those is orders of magnitude more difficult than writing a simple bash script.

To achieve a compromised update you either need to compromise the update infrastructure AND the key or the infratstructure AND exploit the local updater to accept the invalid or forged signature.

As i said, to compromise a signature checked update over the internet you need to compromise both, the distributing infrastructure AND the key. With just either one its not possible. (Ignoring flaws in the code ofc)

You had no idea you could paste a url into a browser's location bar ?

I would feel more comfortable running curl bash from a trusted provider than doing apt get from an unknown software repo. What you are trying to do is establish trust in your supply chain, the delivery vehicle is less important.

Take a look at Shai Hulud. All the attacker had was the key.

Shit are URLs esoteric knowledge now?

Users are blameless, I find the fault with the developers.

Asking users to pipe curl to bash because it's easier for the developer is just the developer being lazy, IMO.

Developers wouldn't get a free pass for taking lazy, insecure shortcuts in programming, I don't know why they should get a free pass on this.

An alternative that will avoid the user agent trick is to curl | cat, which just prints the result of the first command to the console. curl >> filename.sh will write it to a script file that you can review and then mark executable and run if you deem it safe, which is safer than doing a curl | cat followed by a curl | bash (because it's still possible for the 2nd curl to return a different set of commands).

You can control the user agent with curl and spoof a browser's user agent for one fetch, then a second fetch using the normal curl user agent and compare the results to detect malicious urls in an automated way.

A command line analyzer tool would be nice for people who aren't as familiar with the commands (and to defeat obfuscation) and arguments, though I believe the problem is NP, so it won't likely ever be completely foolproof. Though maybe it can be if it is run in a sandbox to see what it does instead of just analyzed.

Yes, the secrets to submit to the distribution system got compromised and therefore the system got compromised.

Running arbitrary text from the internet through an interpreter.. what could possibly go wrong.

I need to set up a website with

fork while 1

...Just so I can (try to) convince people to

curl | perl

it

...rhyme intended.

But what is a trusted provider? How can you trust it? How sure are you that you're not being MitM? Have you fully manually verified that there's no funky flags in curl like -k, that the url is using SSL, that it's a correct url and not pointing at something malicious, etc, etc, etc. There are a lot of manual steps you must verify using this approach, whereas using a package manager all of them get checked automatically, plus some extra checks like hundreds of people validating the content is secure.

To do apt get from an unknown repo, you first need to convince the person to execute root commands they don't understand on their machine to add that unknown repo, if you can convice someone to run an unsafe command with root credentials then the machine is already compromised.

I get your point, random internet scripts are dangerous but random internet packages can also dangerous. But that's a false equivalence because there are lots of safeguards to the packages in the usual way people install them, but less than 0 safeguards to the curl|bash. In a similar manner, if this was a post talking about the dangers of fireworks and how you can blow yourself up using them your answer is "but someone can plant a bomb in the mall I go to, or steal the codes for a nuclear missile and blow me up anyways".

Use our easy bash oneliner to install our software!

Looks inside script

if [ $(command -v apt-get) ]; then apt-get install app; else echo "Unsupported OS"

Still less annoying than trying to build something from source in which the dev claims has like 3 dependencies but in reality requires 500mb of random packages you've never even heard of, all while their build system doesn't do any pre comp checking so the build fails after a solid hours of compilation.

I'm a bit lost with

a more cautious user might first paste the url into the address bar of their web browser to see what the script looks like before running it. In the

You... You just.... You just dump the curl output to file and examine that and then run it if its good

Just a weird imagined sequence to me.

Worse than that, the server can change it's response based on user agent so you need to curl it to a file first, a browser could be served a completely different response.

Which is exactly what is demonstrated in the post. 🙃

I wasn't looking to get roasted for not knowing something. Guess that teaches me something else. Fuck people and thanking them for Shar something I didn't know.

Hahahaha noticed this too. 1.5 was where it was at tho

I think the general response is from confusion over what you could possibly have been using the url bar for in your browser if you didn't know you could put urls there.