3 ms·

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 confi

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.

maccard 4y ago
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.
- Ferret7446 4y ago
  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).
  - ziml77 4y ago
    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
    - maccard 4y ago
      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.
      - ziml77 4y ago
        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.
        maccard 4y ago
        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.
      - justsomehnguy 4y ago
        > 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.
        maccard 4y ago
        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.
  - maccard 4y ago
    > 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.
    - nebulous1 4y ago
      > 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.
bandrami 4y ago
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.

maccard 4y ago

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.

Ferret7446 4y ago
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).
- ziml77 4y ago
  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
  - maccard 4y ago
    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.
    - ziml77 4y ago
      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.
      - maccard 4y ago
        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.
    - justsomehnguy 4y ago
      > 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.
      - maccard 4y ago
        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.
- maccard 4y ago
  > 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.
  - nebulous1 4y ago
    > 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.

bandrami 4y ago

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.