Auto update: Is this secure?

Question

Dot Net Auto Update

I felt like .net was lacking a simple secure automatic update library so I\'ve implemented something and put it up here. Before anyone considers

Answer 1

Just as an addition, add a MD5 CheckSum to the downloaded file as well, otherwise, looking good :) - Fair comment below.

Added:

The only additional thing I can see here is delving into things like obfuscating the code, or archiving the setup file and locking the archive, then once downloaded, unlocking it. That type of thing. However I think what you have currently done should be 100%.

The only time more is needed is when the application is very security complex. Right now you prevent DLL tampering and proof of origin, which for an auto updater, should be plenty.

Answer 2

So I'm not clear on something; the downloader verifies that the manifest is the one it expects, via a signature, does it do the same for the actual patches it installs?

Answer 3

Well, you can try to prevent MITM by having the "no version update" response also include a timestamp (& be signed). Then if a month goes by (or whatever your policy is) with no version change and no timestamp update, then you refuse to run the software or pop-up a warning dialog informing the user there might be a MITM attack.

Doesn't solve the problem of what to do if your server goes down - presumably you treat it the same as a no timestamp change.

Answer 4

Dan Kaminsky has a good set of guidelines for an updater:

To succeed, your update package must be:

• Signed.
• Signed by you.
• Signed by you, using the right EKU (Extended Key Usage)
• Signed from an unrevoked signature
• Be the same product
• Be a new version

From your description in this question, it appears that you have the first 3.

Answer 5

There is some very nice comment and solution in this post. But I am strongly agree with dr. evil. You should use SSL connection for update and the certificate must be saved (built on) in the client. So, you can make sure the client is not going to accept fake certificate. I think it will effectively immune the client from the MiTM attack.

NOTE: If client can accept unauthorized certificate then MiTM attack can be successful, so do not give this option to the client.

Edit: I think SSL certificate can be self signed in this case.

Answer 6

Having build my own deployer in a corporate environment, here are a few use case I needed to address :

• support for digital signature

• support for all kind of proxy. Some big corps have complex proxy configurations (through the use of proxy configuration scripts for example). You should support all of those.

• encryption support. Your customers will probably want to have the deployed binaries available on a web-server, and they won't want to manage some sort of authentication or access control ; but they won't want unauthorized users to download the binaries either. An easy solution is to encrypt the binaries and have your tool deploy it

• support for pluggable additional steps. Corporate clients are usually not very comfortable using automatically deployed tools. They will want more control. Typically, allowing them to run customizable steps (like anti-virus checks, etc) will help

• support for different versions of the software based on the consumer identity. This is often needed in corporate environments, when you want to update the copies of a specific consumer (to fix a bug or add an extra-feature) very fast without running all your Q&A process (in this situation, you want to limit the update to this specific consumer)

• support limited privilege situations. Aside from the fact that your users may lack Administrator access to their computer, big corporations often use specific tools to limit what you can do. Be ready to deploy in a user-owned folder (or even a temporary folder) rather than the classic "program files".

• your tool should be signed by a strong certification authority.

Regarding the MITM attack you mentionned, it's easily solved through the use of public cryptography (as noted by unknown)