Security patches - an additional security issue

Security patches are inherently good

Most people would agree without further reflection that patches/updates that solve security issues in operating systems and applications are needed. They help protecting corporations and end users from malicious software and/or intrusion.

However, there are some issues with security patches that in fact may render certain users more vulnerable. This apparent contradiction will be examined in this article.

A few obvious facts

Security patches are published by software vendors to users of their applications to ensure that vulnerabilites in such applications are removed.

• These vulnerabilities may have been found by the vendors themselves.
• They may have been reported directly to the vendors by responsible third-parties that have discovered the vulnerabilities (by whatever means).
• The vendors may become aware of the vulnerabilities because they see malicious software or published program code that actually utilize the (unpatched) vulnerabilities.

Regardless of how a vulnerability has been brought to a vendor's attentention, the software developer will normally make a patch available for the general public after thorough in-house testing.

The methods for distribution of patches may vary:

• Some publish the patch on their web site.
• Others (like e.g. Norman) have an updating system in the applications that download patches automatically (optionally or not).
• Certain vendors use both methods.

The updating frequency also vary - some publish security patches at a certain time (e.g. Microsoft - normally second Tuesday each month), other issue patches whenever they are seen as necessary. The advantage of the first approach is that corporations can prepare their infrastructure for testing and installing the patches. As some patches may require rebooting critical computers, such preparations are often essential. The advantage of the second approach is that patches can in average be published sooner after a vulnerability has been discovered. Even those vendors, which have standardized on the first approach, may in special situations have to publish patches unscheduled ("out-of-band").

A patch - the foundation for new malware

Unfortunately a patch may in itself be the basis for new malware and thereby result in some users being more vulnerable than without the patch as we claimed above. The reason why is this:

When a patch is released, it is possible to reverse engineer the patch and/or compare a pathced system with an unpatched one. This examination may show what the patch actually does, i.e. which security issue that is fixed by the patch. A malicious person can then develop a program that enables her to exploit a security issue that she was previously unaware of. She knows that patched systems cannot be successfully targeted by her new malware, but unpatched systems are there for her. And we know for a fact that there are lots and lots of unpatched systems out there - days, weeks and months (even years) after a patch is available.

Several applications that are meant to be used as a means to verify that all systems are updated with the latest program updates, can also be used by malicious persons. The person that has developed the malware can use these programs to find computers that are vulnerable for her to attack, so that she does not waste her time on computers that are already secured.

A fact known by the software security industry is that more and more malware use vulnerabilities in applications (often combined with clever social engineering techniques) to propagate successfully. The reason for this is of course that it works...

Reasons - good and bad - for not patching immediately

There are several reasons for not patching immediately after a patch is released.

One bad reason is negligence. The user has not enabled (or even worse; disabled) the automatic updating system that is available in several operating systems and applications, because he does not want to be bothered.

One good reason - which is more interesting in our discussion - is security (sic!).

Many organizations have critical computers (often servers) that "cannot" be unavailable during working hours. Some cannot even be unavailable for extended periods of time outside normal working hours. It is good practice to thoroughly test any new software that is installed on such computers, to ensure that this software does not interfere in an unpredicted manner with software that is already running on the computers. In larger corporations this testing can take a significant length of time, and may have to be planned well in advance.

The general consideration is that it will be a higher security risk for the system to install software updates on these systems without extensive testing,  than to leave the systems vulnerable for a particular security issue during this verification period. This may be a sound decision in most situations.

One reason that cannot be helped without special action is the fact that it takes some time before a patch is released till it is downloaded and ready for installation on computers that have automatic updating enabled. This may be mitigated by downloading the patch manually, but this requires special action, and of course knowledge to the patch's availability.

A kind of case study

As mentioned above some software vendors may see it necessary to issue patches for certain issues outside the general patching sequence. This happened in October this year with a patch from Microsoft published Thursday 23 October (US working hours). An advance notification was released the day before.

According to a blog item from Microsoft this vulnerability was discovered because Microsoft through its monitoring service had discovered targeted attacks against some systems. We can therefore safely assume that exploit code that used the vulnerability was in the public domain. Thus it seems that it was a correct response from Microsoft to release this unscheduled update, as exploitation of the vulnerability could have been extremely critical.

Very soon after the patch was released, malware that utilized the vulnerability was released. E.g. the trojan Gimmiv is reported seen "in the wild" by several antivirus companies. We are not in a position to say for certain that the author(s) of this and other known malware that exploits this security hole, used the reverse engineering technique, but at least it is not a far-fetched assumption. More malware is expected to be developed utilizing this security hole.

This patch was published on a Thursday US time, which means that for major parts of the world it was not available for (automatic) installation before next day's working time. One can assume that many organizations viewed it as too scary to install any program patch on its systems on the day before the weekend, and would have wished that Microsoft had been able to release the patch earlier in the week.

Workarounds for the patch dilemma

The conflicting considerations that have been discussed in this article are not possible to solve completely. However, there are some actions that can be taken on both the patch issuers' and the receivers' side. Some of these are:

• Applications and operating systems should be configured to download patches whenever they are available from the vendor. For critical systems it may be feasible to download and not automatically install (if the updating system offers this option).
• If it applies and is possible - consider (temporary) configurations of the firewall to reduce the probability of being targeted.
• Consider setting up - a priori - emergency patch installation procedures, to be able to install particularly critical patches without following the usual patch verification and testing regime.
• Subscribe to your vendors' security mailing lists to be updated on security issues and patches.
• Deploy security software that is not entirely dependant on signatures to detect malicious software, but also recognizes malicious or suspect behaviour.
• Patch issuers should attempt to avoid issuing patches close to the beginning of weekends and common holidays.