This is part 5 of a series, previous posts: part 1, 2, 3 and 4
In the previous part we finally got our auto-update system working, the only problem is that it only works if we have administrator rights, I find this totally unacceptable (it also doesn't work at all under vista).
The standard solutions is relatively simple, have a second component on the user's system that runs with sufficient privileges and let it do the actual updating, another approach is to prompt the user for the administrator name and password and use them to run a setup program with administrator rights, I don't like this approach – but it is simpler then what I'm suggesting here.
For yaTimer I've written a windows service that is installed with the application and runs at startup, this service runs as system – so it has the required rights to update the application.
This service sets up a .net remoting server - that listens only to connections from the local computer - the update process starts with the application finding and downloading the update (as described in the previous posts in this series), then the application calls the service with the downloaded zip file and the zip's digital signature, the service verifies the signature, unpacks the zip file and executes the updating program.
Just remember, the service has to be light-weight (it is running all the time and it shouldn't affect the computer performance or behavior) and secure.
Securing the service is difficult, here is a partial list of security percussions taken in the service:
- The service does not connect out to the internet, the application does the downloading - that way if someone hacks the site he can't interact with the service directly.
- the service only listens to connections from inside the local computer - This prevents someone from connecting directly to the service over the internet, but it doesn't stop someone who gained limited access to the computer from trying to attack the service, this is an important security measure but not enough.
- I've taken extra care to validate all the data passed into the service - A common form of attack is feeding a program malformed data and exploiting the resulting bugs in the software.
- And finally the digital signature is verified inside the service - I can't trust the application contacting the service (the user might have been infected with a trojan hourse program pretending to be my application).
I won't go into the technical details because writing a good service is difficult and I don't want someone to just go and write one after only reading this post. If you're interested post a message in the comment and I'll write more about coding windows services.
Now, finally we have our auto-update system, you may have noticed I've left two things out – how to replace the application files while it's running and how to update the auto-update service itself, I'm going to write about those two cases in the next post in the series.
posted @ Wednesday, July 4, 2007 2:26 PM