4 ms·

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 usua

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.
      - justsomehnguy 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. 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. Come on, I did deploy PKI and PS Code Signing. [0] https://old.reddit.com/r/PowerShell/comments/kpwi5r/powershell_script_signing_trusted_publisher_prompt/gi4idy1/ https://old.reddit.com/r/PowerShell/comments/kpwi5r/powershe...
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.

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.
    - justsomehnguy 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. 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. Come on, I did deploy PKI and PS Code Signing. [0] https://old.reddit.com/r/PowerShell/comments/kpwi5r/powershell_script_signing_trusted_publisher_prompt/gi4idy1/ https://old.reddit.com/r/PowerShell/comments/kpwi5r/powershe...

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.