Old applications, new vulnerabilities

Patch management tools need to be carefully applied, says Roger A Grimes

One of the best security defences you can have is a fully patched computer. Not just the OS, but all applications — large and small — should be completely up to date. But making sure you have the latest patches isn’t enough. You have to check and see if the older, vulnerable versions of the software you patched aren’t still installed and available.

Unfortunately, many well-known applications, when patched, do not remove the older versions. Malicious websites can often choose which version your client runs, so while you think you’re safe with the latest patches, the older versions of your software can be called, instead, to execute a known vulnerability you had long ago stopped worrying about.

Many patch management tools only check to see that the latest installed software versions are patched. Make sure your patch-scanning tool combs the hard drive looking for old application versions.

One of my favourite tools for detecting missing patches is Secunia’s Software Inspector. It will inspect your hard drive and validate the patch status of more than a thousand popular applications. The Software Inspector comes in a free online Java-based version; a new installable, free, consumer-based executable version; and an enterprise-ready commercial version.

The free consumer executable and commercial versions will not only scan and report, but proactively monitor newly installed software. It’s pretty nifty. (Author’s note: “Nifty” is a technical term).

If you run Secunia Software Inspector, do it in “thorough” mode. It takes a minute or two to run versus 15 seconds for non-thorough mode, but you’ll find more missing patches. I’ve yet to run Software Inspector on a computer for the first time and not find missing patches. What is even more surprising is how often Software Inspector finds older, vulnerable versions of software installed.

Some of the older versions are installed in separate folders, and others are installed alongside newer versions.

The most common applications that I find with previous vulnerable versions are Sun Java, Adobe Flash, Adobe Shockwave, Adobe Acrobat Reader, RealPlayer, and Microsoft .Net Framework. On the Linux/Unix/BSD side, you can add Firefox and Thunderbird, as many users end up installing newer versions to folders named after the new version numbers.

When you update Java, Flash, and .Net Framework using the official mechanism, the package installs the new version, but leaves the previous version behind. Windows/Microsoft Updates detects the older versions of .Net Framework and tries to keep them patched. But Java, Flash, and a score of other vendors add the newer version, leave the older version behind, and never patch it.

Many vendors, particularly Sun and Adobe, are afraid to remove older versions because newer versions can break functionality in older applications. And they have a right to be cautious: I’ve seen thousands of workstations suddenly surface with a “broken” mission-critical application because of an overnight update.

Even if the update breaks applications on, say, only 0.5% of its client base, a large vendor with hundreds of millions of customers is looking at potentially a million or more angry end-users. It’s not a way to grow market share.

But if updates cause problems on only a small minority of systems, is it fair to leave the larger majority at future risk? I wish more vendors would warn users during the install/update that the older versions might be left behind for compatibility reasons, then give users the option to remove the older version during the new install.

Enterprise updates could just install the patch with a switch that forces the old version to stay or be removed.

If this problem of multiple application versions is relatively new to you, or if you haven’t done anything about it, develop a new patch plan of attack and resolve the risk. First, scan for and detect older application versions. When you find these old program versions, make sure they are no longer needed to support other currently used applications.

If not needed, remove or uninstall the older version. Sometimes this is as simple as deleting the older files and/or directory. Occasionally, some programs fight the uninstall process. For example, some older versions of Flash will not let you delete the file, regardless of your admin status.

If this happens in Windows, try the Add/Remove Programs applet, run the program’s custom uninstall program, change permissions to prevent execution, enable the kill bit (if it’s an ActiveX control), or search the internet for additional methods.

Finally, implement a new patching policy that takes older, left-behind application versions into account.

Software vendors, if you don’t uninstall the previous version, let us know about that. Better yet, give us the choice during the upgrade to keep or kill the old version. You’ll get bonus points if you don’t try to sneak unrelated third-party software into your patching process.

Join the newsletter!

Error: Please check your email address.

Tags patch management toolsSecurity ID

Show Comments