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.
Comment on A sneaky demonstration of the dangers of curl bash
xylogx@lemmy.world 1 day ago
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.
axx@slrpnk.net 22 hours ago
Nibodhika@lemmy.world 19 hours ago
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.
xylogx@lemmy.world 18 hours ago
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.
Nibodhika@lemmy.world 7 hours ago
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”.
quick_snail@feddit.nl 1 day ago
Apt is great
ShortN0te@lemmy.ml 1 day ago
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.
xylogx@lemmy.world 1 day ago
Signatures do not help if your distribution infra gets compromised. See Solarwinds and the more recent node.js incidents.
axx@slrpnk.net 22 hours ago
Please tell me you are not seriously equating a highly sophisticated attack line the Solarwind compromise with piping curl to bash?
ShortN0te@lemmy.ml 1 day ago
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.
xylogx@lemmy.world 1 day ago
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