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:
Feb 20th 2008
1 decade ago