Based on Raul's diary last week, I'd like to follow up on updating third party software from a developer's point of view.

Default inbound firewalling has significantly limit the network attack surface posed by core services. Today issues with tools such as Quicktime, Acrobat Reader, Flash, Realplayer and others are causing users to get compromised. The good thing about these massively deployed applications is that they usually have strong update mechanisms. Shortly after a vulnerability is identified and fixed, the user is prompted to update.

This is not the case with all pieces of software, though. There’s plenty of software that is not installed on a whopping 80% of all machines, but is popular with a specific userbase. At the Internet Storm Center, we have recently for example seen the increased use of exploits targeting users of WinRAR, a popular archiver. While each of these vulnerabilities has been remedied years ago, they are still being used to compromise users.

The reason is simple. Some software packages are “tools” that are only run upon opening a specific filetype. These may simply be archives or media files. People don’t expect them to execute code. However, file parsing errors are trivial to make and can quickly lead to code execution.

Infrequent use also means that users will not update these tools. They’re there to be used when needed, maybe only twice a year. There no imminent reason to upgrade. Unless you can’t open the latest gadget, you will not.

As such, developers should really implement mechanisms to prompt users of their software that an update is available. Naturally, plenty can go wrong with an update mechanism, so keep into account that:

• If you expect enterprise deployment, you want to foresee a way to allow corporations to centrally manage the deployed versions or at least disable the mechanism. They prefer not to lose control over their base image.
• You don’t control what your hostname resolves to at the client side. Think about DNS cache poisoning and authenticate your update server to the client;
• Ensure the updates themselves are signed, so clients can check their integrity;
• Ensure users are made aware of the difference between a security and functionality update;
• Let the client report its version to the update server, so it is aware if a large part of the userbase isn't upgrading, and you can find out why.