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 using the library I was keen for the update process to get a bit a peer review.

Here are the steps:

• The client software is populated with a public key and URI to poll.
• Client polls a URI for a manifest file.
• Manifest is downloaded and signature (in a separate ".signature") is used to check that the manifest is valid.
• A list of pending updates is parsed out of the manifest (to show to the user).
• The installer file is downloaded and again is verified with a corresponding ".signature" file. (the downloaded file will be protected with ACLs)
• The installer is run.

Mitigated threats:

• The manifest signature should prevent any malicious downloads ("carpet bombing")
• The installer signature should prevent any MITM attacks from sending malicious installers
• Protecting the downloaded installer with ACLs should prevent any local escalation attacks.

Unmitigated threats:

• A MITM attack where the attacker always reports "no updates available". (Could keep a client at a vulnerable version)

References:

• Secure Software Updates: Disappointments and New Challenges
• Black Ops 2008: It’s The End Of The Cache As We Know It
• Evilgrade Will Destroy Us All

What have I missed?

Answer 1

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 2

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)

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

Don't mean to be troll in here, but you are trying to solve an already solved problem. Using SSL would be a much better choice. That would solve all problems listed in your question.

I understand that this system can be useful for people who can't afford an SSL certificate but anyone who can get one, should get one to solve this problem.

Don't forget, "Complexity is the enemy of security".

Answer 5

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 6

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 7

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.