Security Risks of Unsigned ClickOnce Manifests

Question

Using signed manifests in ClickOnce deployments, it is not possible to modify files after the deployment package has been published - installation will fail as hash information in the manifest won't match up with the modified files. I recently stumbled upon a situation where this was problematic - customers need to be able to set things like connection strings in app.config before deploying the software to their users.

I got round the problem by un-checking the option to "Sign the ClickOnce manifests" in VS2010 and explicitly excluding the app.config file from the list of files to have hashes generated during the publish process.

From a related page on MSDN

"Unsigned manifests can simplify development and testing of your application. However, unsigned manifests introduce substantial security risks in a production environment. Only consider using unsigned manifests if your ClickOnce application runs on computers within an intranet that is completely isolated from the internet or other sources of malicious code."

In my situation, this isn't an immediate problem - the deployment won't be internet-facing. However, I'm curious to learn what the "substantial security risks" of what I've done would be if it was internet-facing (or if things changed and it needed to be in the future).

Thanks in advance!

---

Edit / follow-up:

Does not signing the ClickOnce manifest constitute an unsigned manifest (as per MSDN's definition)? The application manifest contains a hash of the files in the deployment package. Any changes to the files within it results in a validation failure during installation. Does this negate the above security risks, at all?

Answer 1

I imagine the risks are the same as using any unsigned executable. The reason that it's okay to download the application over an intranet is that you trust the network hardware (and people who have access to that hardware) that serves you the file. When you ask, "Server foo.local, please send me bar.exe," you know that foo.local is a trustworthy machine, and all the routers and switches between you and foo.local are also trustworthy.

In an Internet distribution setup, the user asks foo.com to serve bar.exe. The user has no good way to be sure that:

• foo.com hasn't tampered with the file
• his DNS records haven't been tampered with to keep him from talking to the right host
• that an attacker on his home network hasn't ARP poisoned his router to redirect and alter his traffic

The user gets the file from a fundamentally untrustworthy source. Digital signatures are a way to provide trust even when the distributing source is not trustworthy. The signature is a sealed guarantee to the end recipient that this file is exactly the one that was produced by the original signer.

Ultimately, the risk is not that the file will somehow be less trustworthy when it reaches the user; the problem is that the user may not ever receive your file, but will instead be unknowingly provided with a different file. Digital signatures allow you to mark your files as uniquely yours, in a way that can be verified by the end user. Any malicious agent who tries to provide a malicious lookalike will not be able to fake your signature. However, if you don't have a signature in the first place (or, more importantly, the user is not expecting a signature), then there's no way to verify he got the right file.