I set up a quick demonstration to show risks of curl|bash and how a bad-actor could potentially hide a malicious script that appears safe.
It’s nothing new or groundbreaking, but I figure it never hurts to have another reminder.
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. 🙃
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.
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 | perlit
…rhyme intended.
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.
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.
Never have I ever piped curl to bash.
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!
Shit are URLs esoteric knowledge now?
You had no idea you could paste a url into a browser’s location bar ?
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.
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.
Oh, people will keep using it no matter how much you warn them.
Proxmox-helper-scripts is a perfect example. They’ll agree with you until that site comes up, and then its “it’ll never, ever get hacked and subverted, nope, can’t happen, impossible”.
Wankers.
@K3can@lemmy.radio love the early 2000s stylesheet/color theme of your blog 🙂
Thanks! I like to keep things simple. The colors are based on Counter Strike 1.6. 😁
And if you’re into the classic styling, my homepage is a direct homage to my old 2000s sites.
You mean blindly running code is bad? /s
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.
Wow, I never thought anyone would be that dumb.
Why wouldn’t they just wget it, read it, and then execute it?
Oh the example in the article is the nice version if this attack.
Checking the script as downloaded by wget or curl and then piping curl to bash is still a terrible idea, as you have no guarantee you’ll get the same script in both cases:
Anytime I see a project that had this in their install instructions, I don’t use that project.
It shows how dumb the devs are
Yes, this is the correct approach from a security perspective.
Yes this has risks. At the same time anytime you run any piece of software you are facing the same risks, especially if that software is updated from the internet. Take a look at the NIST docs in software supply chain risks.
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.
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.
This is a bit like saying crossing the street blindfolded while juggling chainsaws and crossing the street on a pedestrian crossing while the light is red for cars both carry risk. Sure. One’s a terrible idea though.
Not completely correct. A lot of updaters work with signatures to verify that what was downloaded is signed by the correct key.
With bash curl there is no such check in place.
So strictly speeking it is not the same.
Signatures do not help if your distribution infra gets compromised. See Solarwinds and the more recent node.js incidents.
Please tell me you are not seriously equating a highly sophisticated attack line the Solarwind compromise with piping curl to bash?
This is incorrect. If the update you download is compromised then the signature is invalid and the update fails.
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.
If I can control your infra I can alter what is a valid signature. It has happened. It will happen again. Digital signatures are not sufficient by themselves to prevent supply chain risks. Depending on your threat model, you need to assume advanced adversaries will seek to gain a foothold in your environment by attacking your software supplier. in these types of attacks threat actors can and will take control over the distribution mechanisms deploying trojaned backdoors as part of legitimately signed updates. It is a complex problem and I highly encourage you to read the NIST guidance to understand just how deep the rabbit hole goes.
Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
No you cannot, the pub key either needs to be present on the updater or uses infrastructure that is not owned by you. Usually how most software suppliers are doing it the public key is supplied within the updater.
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-Huludvia theGitHub/user/reposAPI. - 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]"
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.
Curl bash is no different than running an sh script you dont know manually…
No, it is different, as it adds an entire layer of indirection and unknown to the mix, increasing the risk in the process.
True, but this is specifically about scripts you think you know, and how curl bash might trick you into running a different script entirely.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters DNS Domain Name Service/System HTTP Hypertext Transfer Protocol, the Web PiHole Network-wide ad-blocker (DNS sinkhole) SSL Secure Sockets Layer, for transparent encryption TLS Transport Layer Security, supersedes SSL VPS Virtual Private Server (opposed to shared hosting)
5 acronyms in this thread; the most compressed thread commented on today has 12 acronyms.
[Thread #111 for this comm, first seen 23rd Feb 2026, 04:40] [FAQ] [Full list] [Contact] [Source code]
