5

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?

Tom Tom
  • 419
  • 4
  • 12
  • It occurs to me that you could be asking two different questions. The first could be "What are the dangers of unsigned files?" (which I address below) but a second could be "What are dangers of allowing an attacker to arbitrarily rewrite my ClickOnce manifest?" (which I have not fully addressed). – apsillers Jun 26 '13 at 18:43
  • You might want to consider storing the connection info in an external file (not part of the manifest) and you can store the URL for the file in your app.config. It is a little more work, but it keeps things more loosely bound without compromising your manifests. – TimG Jul 02 '13 at 18:57

1 Answers1

7

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.

apsillers
  • 5,083
  • 25
  • 33
  • Great info. / overview - thanks. My only remaining question is ClickOnce-specific. Despite electing _not_ to sign the ClickOnce manifest, the application manifest still contains a hash of the deployment package files. Changing the contents of the package causes validation to fail. Does this negate the security risk, at all? – Tom Tom Jul 02 '13 at 10:58
  • 2
    @TomTom I don't believe so, as long as the attacker can replace the hash as well. Suppose you have a set of genuine files `F` which produce a hash `H`. The attacker modifies your files in transit so they are now a set of files `F'` with a different hash `H'`. The attacker can simply send `H'` as the manifest hash, and the end user is none the wiser that there was a different hash `H` originally. – apsillers Jul 02 '13 at 13:13
  • 1
    The benefit of the signature: assuming you have a signing function `S(input, private_key)` and a private key `privKey`, you can generate `S(H, privKey)`. The attacker *cannot* generate a signature `S(H', privKey)` for his new hash because he doesn't have your private key. – apsillers Jul 02 '13 at 13:18
  • @apsillers without a trusted 3rd party / certificate authority (IIRC, the ClickOnce model doesn't make use of them), what's stopping the attacker from using their own keys? – Daniel B Jul 03 '13 at 05:51
  • @DanielB ClickOnce signed manifests [must come with a certificate](http://msdn.microsoft.com/en-us/library/ms172240%28v=vs.80%29.aspx), but it's up to the discretion of the project creator whether that certificate is self-issued or from a trusted CA. Indeed, as you say, if you choose not to use a trusted CA, there's no reason why an attacker couldn't substitute your self-issued cert with his own. – apsillers Jul 03 '13 at 13:01