@marcan The worst-case scenario isn't that your web...

The worst-case scenario isn't that your web server is hacked and somebody starts installing malware instead of your tool. The worst case scenario is that this happens and the source of malware goes on undetected for years because the web server gives different scripts to different people.

Additionally, curl|sh will seriously hamper incident response people figuring out the source of malware, because it doesn't save the script that was run anywhere.

1/2

Like 23 May at 13:23 | Wall-to-wall | Open on hachyderm.io

4 comments

mppf

@marcan

If you think about the open-source security model, it's arguably more based on auditing than anything else. Because everyone can see the same code, we like to think someone will notice a problem. curl|sh breaks that because people might get different code.

A reasonable alternative is to replace the paste-able curl|sh command with a paste-able command sequence which 1) downloads the install script and saves it to a file 2) verifies a checksum on that file 3) executes it

2/2

23 May at 13:24 | Open on hachyderm.io

Hector Martin

@mppf *Any* download mechanism can serve different files to different people. Your idea just moves the attack point to the web server serving the instructions, such that they serve different checksums to different people, to match with the different files they're going to get.

You are just one more person arguing against curl|sh while completely missing that the problems you raise literally apply to every other competing approach. Seriously, stop and think please. I'm tired of having the same conversation over and over again.

The only way you can verify *anything* is against an existing root of trust, and the only root of trust that exists on the system is the WebPKI, which means you can trust a server is not spoofed, and yes, means you still have to trust the server itself, because there's no way around that (other than switching to Apple's walled garden codesigning, which has its own root of trust and yes, is in the cards some day, but that's a much more difficult project and it's never what the anti curl|sh people actually suggest).

Expand text...

23 May at 13:32 | Open on social.treehouse.systems

Hector Martin

@mppf If our web server gets hacked it could serve different images to different people regardless of the verification/delivery mechanism. The attacker just has to change the SHA hash or PGP key or whatever else security theatre approach you use to "verify" the file with data coming from a web server anyway.

The script is just a bootstrap. The actual installer gets downloaded and unpacked to /tmp. Yes a malicious script could do something non persistent directly in the bootstrap. But a malicious download could also self-modify to erase the malicious part after it's done. This is a red herring.

That is: none of your arguments are arguments against curl|sh that don't also apply to everything else.

Expand text...

23 May at 13:27 | Open on social.treehouse.systems

mppf

@marcan That's true but misses something important about security measures. They are about making it harder for somebody to do something bad, not to necessarily prevent it entirely. Having to change a SHA hash in a coordinated way is tricky for an attacker and significantly increases the difficulty.

Also, publish the SHA hash etc makes it much easier for people to compare notes and especially makes figuring out what happened easier in the context of incident response.

23 May at 13:31 | Open on hachyderm.io