Hacker News Reader

Comment by bmandale | Hacker News Reader

> even people who (rightly) hate the "curl | bash" combo. You could be running anything.

That's true unless I audit every single line, out of potentially millions, in the source of a program I intend to run. If I'm going to do that, then I could audit the ./configure script as well.

View on HN

This is missing the point. The issue with "configure" is that it is easy to hide malicious code in it because it is so arcane. The issue with "curl | bash" is that - on top - there is not even a proper trust chain and independent verification. "curl | bash" needs to die. Any project who promotes this does not care or does not understand security. "configure" was a necessary evil in the past with all commercial UNIX working differently. Nowadays I think it should go away.

> "curl | bash" needs to die. Any project who promotes this does not care or does not understand security.

Do you "understand security"? There's a grain of truth to what you're saying, but not more than that. The crux of this problem is with running untrusted binaries (or unreviewed source code) vs. installing something from a trusted repository.

The majority of people either don't know or don't care to review the source code. They simply run the commands displayed on the website, and whether you ask them to "curl | bash" or "wget && apt install ./some.deb" won't make any difference to their security.

Even if you do a "proper trust chain" and digitally sign your packages, that key is served through the same channel as the installation instructions and thus requires trust on first use, just like "curl | bash".

Unfortunately publishing every piece of software through every operating system's default repository isn't very realistic. Someone, somewhere is going to have to install the binary manually and "curl | bash" is as good of a method for doing that as any.

If people install random stuff from the internet, there is no security. That sometimes this is done is no reason to give up and teach people that "curl | bash" is even remotely ok. "curl | bash" is much worse than every other way to install things from the internet, because there is no guarantee that what one persons gets the same what anybody else gets, so any kind of chance to even discover a compromise is lost.

> because there is no guarantee that what one persons gets the same what anybody else gets, so any kind of chance to even discover a compromise is lost.

This applies to "curl | bash", "download an exe and run it", and everything in between equally. If a malicious binary wants to cover up its tracks it can just delete itself and disappear just like "curl | bash" would.

Feel free to educate users about the importance of installing software from trusted repositories whenever possible but demonizing "curl | bash" like it's somehow uniquely terrible is just silly and misses the point completely.

With a binary, one can compare a hash or store a copy on the binary on another computer. And one person doing this might be enough to figure out something is wrong. But even if people don't, it needs additional effort by the attacker to search for the binary and clean up their tracks, which also creates more opportunities for detection. It is really not at all comparable to "curl | bash". You sound like the people who told me two decades ago that reproducible builds are a waste of time.

> With a binary, one can compare a hash

You lift a suspected binary from a machine that's under suspicion. You hash it and it matches a known good file. You declare victory, pat yourself on the back, and return it back into service. 3 months later all of your data is exfiltrated because you assumed that your attacker is an idiot.

> it needs additional effort by the attacker to search for the binary

Additional effort:

    #include "stdio.h"
    #include "unistd.h"
    
    void main() {
      char path[512];
      readlink("/proc/self/exe", path, sizeof(path));
      unlink(path);
      printf("Poof, I disappeared from: %s\n", path);
    }

> You sound like the people who told me two decades ago that reproducible builds are a waste of time.

Except I wouldn't say that because these ideas are completely unrelated. Define your threat model and specify what problem you're trying to solve. Don't be the type of person who encrypts passwords because they heard that encryption is good for protecting data.

You demonized curl|bash because it "doesn't have a proper trust chain" and attacked the project for "not understanding security" with really weak arguments, now you're retreating all the way back to claim some fringe benefits to maybe-possibly discover the source of infection, and only if your attacker is lazy not to try to cover their tracks.

Continuing that argument like it's the same one you originally presented is quite a disrespectful way of wasting people's time: https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy

You can copy the binary on a different system before installing it, or compute the hash before you run it. This is not hard. And even if you are not copying to another system, the attacker needs to find all copies of the binary and modify them. Also note that the installer binary / script is not the same as the binary that later runs. And any additional effort the attacker has to do to hide its tracks also increases chances for detection, this is also something that can be learned from XZ backdoor.

Autotools is a hot mess. Anything complex is going to be a rich environment for exploits of all kinds. The more silent the exploit the bigger the chance that it will spread widely.

Reply on news.ycombinator.com