A signed Squirrel binary can be used to execute untrusted code about clowd.squirrel HOT 8 CLOSED

I think we can do better. It's still possible to run unsigned code from a trusted binary (although I won't mention how here) or ask Squirrel to download any arbitrary code from any untrusted url.

The main argument for keeping these command line arguments at all are for native app support (eg. electron/windows-installer).

1. For the "running untrusted code" bit, it should be possible to do a better job of only starting signed binaries in all the places it can be done in an installed app. I do not think we can verify that the signature is the same as ours safely - it could cause issues when changing an expired certificate, and we also allow already-signed exe's (with a different signature) to be included in packages. All we can check safely is that Windows trusts it, and that should (probably?) be enough.

2. For the "downloading/unpacking/updating-to untrusted code" bits, we need to lock down some of the endpoints - any argument that can be fed into new UpdateManager(string urlOrPath) needs to have some kind of guard. Just thinking out loud about a couple of ideas:

   • We could add a --authorizedHosts="*.google.com,*.mydomain.com" argument which gets embedded into Update.exe as a resource. Functional, but requires you to know your domain in advance when building packages, and makes moving domains harder (needs to be a multi-step update)
   • If --signParams is specified, we could mandatorily ask for a private key (--signKey=) and use that to sign each release. Nuget packages already support signing and we can embed the certificate fingerprint in Update.exe.

from clowd.squirrel.

For "downloading/unpacking/updating-to untrusted code", branch cs/better-signing has some PoC code which implements nuget package signing and package signature verification in Update.exe.

One consideration is I am not sure how to allow you to change your code signing certificate. If Update.exe is verifying the certificate of packages before installing/unpacking them, and you lose your certificate it or it expires and needs to be replaced, your app would effectively be bricked from ever receiving updates again.

I should also have a look through this and review the AuthenticodeTools class
https://github.com/microsoft/Windows-classic-samples/blob/main/Samples/Security/CodeSigning/cpp/codesigning.cpp

from clowd.squirrel.

Not one hundred percent secure but at least as an additional validation: Maybe we can check if the common name (CN) of the update nuget package’s signature is the same as the one of the signed update.exe? That would at least allow to replace the certificate if it expires …

from clowd.squirrel.

Some thoughts on certificate validation. Policy. It might be nice with some choice since use cases might differ.

If I remember correctly for clickonce you can change certificate to any new certificate as long as you don't change anything else (name/url).

Different possible certificate check policies:

• any (valid and trusted) certificate
• same CN/DN
• Bundle list if valid certificates (or do double signing with both old and new when changing certificate)
• no signing (same as current)

Other thoughts:

• for manual update, it might be good to allow implementing other policies
• Even a hardcoded "require any valid signature" is a step up from now
• Ensure sha1 is not used for hashes
• how to handle signature policy mismatch?
  • show a ui with the "error/warning" and still allow installation?

from clowd.squirrel.

If Update.exe is signed, we could check the --processStart binary for trust too, and only run if it's also trusted.
https://stackoverflow.com/questions/24060009/checking-digital-signature-on-exe

from clowd.squirrel.

Closed by d9b740d

from clowd.squirrel.

Package signing is largely implemented as a PoC, but there are issues here I've already mentioned that I'm not sure how to workaround at the moment, so I am closing this unless there is a suggestion on how to allow codesign certificate updates.

from clowd.squirrel.

All good suggestions. I like the idea of showing a warning with a signature mismatch instead of failing to update, but we have limited options as far as UI goes. It's the same issue we have when an app has been updated and requires a new runtime dependency (like net5/6/7/beyond). Most of the time it's the user application doing the update in the background, using the C# package, and not Squirrel / update.exe.

For installing, it doesn't really matter because the package is bundled with the exe and everything is signed.

Updating is the main issue here, because you can theoretically execute Update.exe --update {url} in any squirrel app, and it will update to anything (even a different app, or download a malicious payload). This is the API used by native / non-C# apps, so if we intend to support people with native apps migrating from the old squirrel to this one, we need to keep this API and secure it optionally like you suggest.

One last consideration is that it's always a fine line between "configurable" and "ease of use". If we have too many options, it can be prohibitive for new users trying to understand how things work. (Squirrel is already hella complicated, and I'm doing my best to keep the command line as simple as possible!)

I'd be happy to re-open this if someone is willing to help out with an implementation?

from clowd.squirrel.