Reputability won't help you if someone intercepts your connection and replaces the script. TLS helps, insofar as the version of curl you're using and its configuration is correct, your machine has the right certs installed, and the remote domain and/or host and/or repo hasn't been hijacked.
If eithet you or the host have been compromised, it doesn't matter where you curl into bash, run pip install or download an exe/dmg/deb file - you're hosed.
Packages are signed, unless you're using a niche, insecure distro or package manager. Of course, that signing key could also be compromised, but those are usually more tightly guarded than web servers, which are compromised rather more frequently (any reputable dev should have their key in a hardware enclave like yubikey or similar).
> Packages are signed, unless you're using a niche, insecure distro or package manager.
You still need to get that signature from somewhere, likely a web server. If your threat model is that you don't trust web servers but do trust the packages and repositories they give to you, then I guess this is true but that seems a little crazy given that the attacker can just change the website you're visiting to host a malicious package, and change the signature it verifies against.
> Of course, that signing key could also be compromised, but those are usually more tightly guarded than web servers,
Why is it reasonable to assume that? I don't think it is, at all. If their SSL certs are comprised, all bets are off.
> any reputable dev should have their key in a hardware enclave like yubikey or similar).
I suspect you will be very very very disappointed at the number of people who publish software that meet the criteria you've outlaid here.
Fundamentally, your argument is flawed right at the beginning because all the attacker needs to do is compromise the web server and change the installation instructions.
> Why is it reasonable to assume that? I don't think it is, at all. If their SSL certs are comprised, all bets are off.
I have no statistics to offer, but it does seem likely to me that TLS private keys gets compromised more frequently than software/package signing keys.
Then maybe a solution is script signing. PowerShell scripts can contain a signature at the end, and the shell will check that signature. It can either be mandated all the time or only if the script originally comes from a remote source (or disabled completely if you don’t care). Since it’s just a comment block, it’s fully backwards compatible to add too
This solves the part of downloading partial scripts, but doesn't solve the problem of malicious scripts. If you download a script from a compromised host, they'll just re-sign the modified script with their own signature. The solution is that you have to trust the script source, and transmit over secure channels.
If they sign the script with their own signature then it’s no longer a script that you trust. I can’t remember if PowerShell automatically trusts a script that’s been signed by a cert issued by someone like VeriSign, but if the system were to be adopted for Bash scripts there’s no reason it couldn’t use a store that only trusts the distro maintainers by default.
If it only trusts the certs from distro maintainers then surely it will be distributed as part of the normal package sources. If you need to add a cert, then the problem is exactly the same as adding a repository to the package manager; if the delivery mechanism of the instructions is compromised you're hosed.
Powershell will accept codesigning certs that are signed by verisign, so the workaround for an attacker who has already compromised a web site is to modify and re-sign the script with a certificate that can be obtained for $60.
> they'll just re-sign the modified script with their own signature
Nope. Of course if someone stores a Code Signing key on the same server as the distribution server then all bets are off, but otherwise it's no possible.
PS CodeSign isn't perfect, but there is enough hoops to jump around for this not to be an easy task for a malicious actor gained access a distribution point.
If I take a script, modify it and re sign it with a valid key, it will still be signed, just not by the original author, and will run.
Even on windows now, package are often signed by individual developers rather than an entity that you might recognise the name of.
> but there is enough hoops to jump around for this not to be an easy task for a malicious actor gained access a distribution point.
If this is an optional step (which it would have to be) then the easiest thing to do is to remove the signature from the script and modify the instructions on how to run the script. If an attacker has compromised the supply chain, unless the original host has done something incredibly dumb, chances are they're quite dedicated and jumping through a handful of extra steps arent going to stop them.
> If I take a script, modify it and re sign it with a valid key, it will still be signed, just not by the original author, and will run.
> Even on windows now, package are often signed by individual developers rather than an entity that you might recognise the name of.
This is implies what you, as an attacker:
have the access to the Enterprise PKI
can issue code signing certificates
somehow your certificate drops in the Trusted Publishers[0] on the endpoint ie you have the access or to the GPO/domain controllers (keys to the kingdom) or to the endpoint (making the whole dance with certs moot)
> If this is an optional step (which it would have to be) then the easiest thing to do is to remove the signature from the script
This would make the script to fail from running in a proper configuration
> and modify the instructions on how to run the script.
And again this requires the access to the endpoint, which makes your assumptions moot.
> If an attacker has compromised the supply chain, unless the original host has done something incredibly dumb, chances are they're quite dedicated and jumping through a handful of extra steps arent going to stop them.
Exactly, which is why you don't "signed by individual developers", don't provide the easy way to access the PKI, don't sign the scripts and yet run them with -bypass.
and the CA who signed the package isn’t a bad actor. But there are known bad actors in the ca-certificates list and worse yet they can sign any certificate.
