I have been introduced to the anti-bash-script-piping stuff such as these:
- Curl Bash Piping Wall of Shame (link broken)
- Piping curl to s(hell)
- Don't Pipe to your Shell
- The hidden dangers of piping curl and how to protect yourself
- ...
The gist of it is that:
- A browser can show you one snippet of code and then curl downloads another. This is just simple user agent sniffing.
- Someone can hijack your server and send malicious code instead of what you expect.
The solution is said to use a "package management with hash databases, to ensure you are receiving the same code as others... though with hashing you've got effective post-release protection against a compromised source injecting malicious data at the very least". To me this is a bit over my head or not worded very clearly.
This gets more at my point:
People who pipe it to a shell aren't going to look at it anyway. That's kind of the point. If they were, they'd download it first. There is literally no security gained by downloading it and running it, instead of just
curl|sh
. IF it's malicious, you just installed it either way. The only thing downloading does in this scenario is lets you look at the script later on when you realize it might have been malicious, but that's even assuming you kept it (I would wager that almost everybody would throw away the script after installing it if they weren't planning on reading it before installation), and assuming you know enough to understand its contents (not everybody knows bash scripting, and you can write some surprisingly complex scripts).
It seems that when you install anything you should really be reading the source code first. Similar to how you should really be reading the Terms of Service before signing up for a service. But I imagine not many people actually do this.
Another user states:
The correct thing to do is distribute via cryptographically signed archives or packages, or via signed git tags.
How does this work??
Say I have an application or "install" of several files. I get the MD5 hash of the file. Now if I change the contents of the application/install, the MD5 will change. I get that much. What I don't get is how everything else fits into the picture.
- Is the one doing the downloading supposed to verify the download is correct? That is, are they supposed to run the md5 hash algorithm on the contents and compare it with some existing hash?
- And where does that "existing hash" come from? Is it part of the download itself? Couldn't that simply be regenerated and appended to the download after the files were already changed? How do you guarantee the MD5 hash is the "original" MD5 hash, whatever that means.
- It sounds like they are saying to use a third party service to upload like a zip with an MD5 hash; some package manager that will distribute the "original" md5 hash with the zip file. In this situation, then you would download from the package manager, then manually check the MD5 hash? Or how does that work, who does the checking? Where is the original MD5 hash kept? How do you know it hasn't been tampered with?
- Given that they've downloaded the MD5 hash and checked it, it could still be tampered with and just published a corrupt version on purpose. So you still have to manually check the file contents before installing, correct? Or where am I going wrong?
- Even if you checked it, you might have missed an extra carefully placed snippet of code, and installed anyways. In that case what good was the whole process above? A good attacker would remove their tracks and so remove the file after installation, so you would never be able to tell.
Give all of this, I don't see how using a hash/crypto package manager setup for installs is any more secure than just copying code from which you may only vaguely know of the author, and just pasting it into the terminal. In that case you would still have the logs at least (terminal logs) to go back and check. Or perhaps the attacker could get rid of that too.
Then if an attacker can get rid of their traces no matter how "secure" this hash/crypto package manager system is (and manual source code checking), what difference does it make using bash script piping vs. package manager? Why is a package manager better is the crux of the question.
In the end it seems to simply boil down to trust. If you trust the author, then it doesn't matter which way you choose to install it. Maybe this is why Apple more heavily regulates what apps get uploaded to their app store (from what I've only heard); they want to make sure no security problems are there hidden away. So they prompt you "Are you sure you want to install this script from an unidentified developer on the internet" type thing, if they didn't go through the Apple store.
But even at the some of the most secure companies I bet they let their developers install things such as Sublime, straight from the developer's website rather than the App Store, and it is closed source so there is no way to inspect the code. It could be doing anything.
So basically, what good is a third-party hash/crypto based package manager install solution over curl bash script piping. In some detail please.