1

I have been introduced to the anti-bash-script-piping stuff such as these:

The gist of it is that:

  1. A browser can show you one snippet of code and then curl downloads another. This is just simple user agent sniffing.
  2. 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.

  1. 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?
  2. 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.
  3. 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?
  4. 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?
  5. 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.

2 Answers 2

1

So basically, what good is a third-party hash/crypto based package manager install solution over curl bash script piping. In some detail please.

None, if you uncritically trust the repositories you add. This is universal. If you trust bad people, bad things happen.

The major Linux distributions have package repositories that restricts addition of packages to people trusted by the project. There's some process of curation, to ensure that multiple people looks at important things, and changes are documented and stored in a version control system.

If you install the distribution in the first place, it doesn't make sense not to trust the repositories, as you already installed a lot of software from them.

In short, we trust them because they have proven rather trustworthy over a long time. I am not aware of malware being distributed in any major distributions repositories for instance.

If you choose to add a repository signed by John B. Evil you can be sure that the packages comes from someone controlling the key for John B. Evil, but you don't have any idea about the quality of the packages.

The crypto is to ensure that a malicious mirror or someone able to inject data at will in the network stream can't send you malware. The keys are distributed ahead of time, as part of the installation, and the installation medium can usually be verified as well via a check sum transmitted over a secure (TLS) link.

In short; cryptographics doesn't ensure data is not evil. It only ensures integrity.

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?

Check sums (and cryptographically secure hashes) only ensures integrity. If I tell you that the file with the sha256sum 1ed43276361671bef0f74918df9ccf0dcd7ca7a0414c53116ad1ed9c84fbf367 is safe, and you trust me, you can get this file from anywhere, and verify the checksum. You don't have to get my copy, because you know any copy you find with this checksum is identical to mine.

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.

The Linux distro Example may host a website secured by TLS at example.org, which publishes the hash. To get a faster download, I may download the file from some mirror in my country, run by unknown entities. I can verify the hash, and thus be certain that the file is equal, without having to trust mirror. The check sum is a small piece of data (order of tens or hundreds of bytes), so it's very cheap to transmit.

The bottom line is that you have to trust someone. Hashes is a technical way of enforcing trust.

2
  • y.org is the ymca, what did you mean exactly?
    – Lance
    Jul 8, 2019 at 3:18
  • It was used as an example. I replaced it with Example and example.org to make it more explicit. Insert Debian and debian.org if you prefer.
    – vidarlo
    Jul 8, 2019 at 3:28
0

The root of the reason why installing packages from package manager repositories are more secure than doing a curl | sh is that it moves the burden of verifying the install script and the software to the package maintainers. There are various mechanism and policies in place, but package signing is the primary mechanism that allows them to do this, combined with the repo's inclusion policy which defines the minimum security requirements for the addition of a software to their repository.

The package maintainers privilege in most of the major Linux distros are limited to people who have shown to be trustworthy and have the technical capabilities to notice when things looks off. The package maintainers are someone who knows the distro's packaging policy very well, and they usually works very closely with the core developers of the software to ensure they themselves downloaded the untampered software from the original software source. The package maintainers also maintains the build script for those packages.

Note that not all package managers are created equal. Packages from Ubuntu's and Debian's main repositories are curated, but Snap packages are not curated. If you added a PPA or AUR repo, packages from those repos are user submitted and are not curated. If you install packages from alternate, language specific package managers, like PyPI, these are usually not curated either.

What are the weakness of this system? You still have to trust the distro maintainers that they don't invite a new maintainer with malicious intent. New maintainers have to show a long history of work with the core distro maintainer before they are given trust privilege. The maintainer also have limited time and resources to notice and QA a package, especially if the original software vendor turned malicious. Most of the major distros have various checks and balances to minimise the chances things like these from slipping through, and while they're not perfect, the major distros' processes and policies will definitely beat any single company's or individual's effort at doing these verifications.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .