What Is a Patch?

What Is a Patch?

What is a patch? Well, actually, the term could mean a number of things. Microsoft has a very specific nomenclature around patches. For more information, see Microsoft Knowledge Base article 824684: "Description of the standard terminology that is used to describe Microsoft software updates." When security administrators refer to a "patch," what we usually mean is actually what Microsoft calls a "security update." There are other types of patches, too, that have nothing to do with security. From now on, when we use the term patch , we are using it in the general sense of a patch, which could be from any vendor. We also use the standard terms patching and patch management to refer to the process of applying such a patch and the general management thereof, respectively. When we are referring specifically to fixes for security issues in Microsoft products, we use the term security update .

The official definition of a security update according to the KB article is a broadly released fix for some kind of security issue that can be used to exploit a system. Typically, security updates are only published for security issues that have already been made public, or will be made public shortly. The types of issues for which security updates are issued are also important. A 0-day vulnerability is a vulnerability that was used in the wild before the vendor, or anyone else, was notified of the problem. We prefer to distinguish these from the second category, 0.5 days, which are issues that have been made public first, and then exploited, before the vendor has time to produce a patch. The difference between a 0 day and a 0.5 day is simply that in the latter the issue is made public before being exploited. Many security professionals do not use this distinction, however, but it is interesting. Whereas 0 days in Windows have been very rareto our knowledge, there have only ever been less than a handful of these on the Windows platform0.5 days are quite common. Microsoft Internet Explorer (IE), in particular, has been subject to quite a few 0.5 days. It is interesting to note that issues for which no vendor patch is available are much more commonly exploited if they were publicly announced. There is a very strong correlation between public announcement of a vulnerability and exploitation, particularly, it seems, if no vendor patch is available at the time of the public announcement.

This correlation has given rise to calls for standards of "responsible disclosure," whereby the vendor gets a chance to address the problem before the finder makes the findings public. Unfortunately, some application security analysts, seemingly for purely pecuniary or vindictive reasons, decide to play outside these proposed societal norms of good behavior; putting users at risk and making the vendor rush out patches that may not be of the same quality as a carefully developed and tested one. Most of the Microsoft security updates that have been recalled and re-released, for instance, were released in this way.

The third category of security issues is where the finder reports the problem to the vendor and then gives the vendor sufficient time to address the issue properly before reporting the findings publicly. The definition of "sufficient time" here differs , but could be quite significant if the issue is complicated, if it applies to several product versions, or both. Although development of the fix may be easy, the test matrix can be huge. For example, between all supported versions and languages of IE, a security update may need to be produced and tested in more than 300 versions.

One variant conspicuously absent from the types of issues fixed in patches is fixes for vulnerabilities found by the vendor. In rare instances, where such a problem is believed to be externally known, or where the likelihood of discovery is high, a vendor may release a security update for an internally found security issue. Often these internally discovered vulnerabilities are found while producing a security update for an externally discovered security issue in the same component. In these cases, the security update usually fixes all the problems. However, during the regular development process, a developer or tester may find a security issue in some component. These issues are often handled just like any other bug. If there is no reason to believe that it is or will be externally known, the fix is often held for the next major or minor release, such as a service pack. Service packs are generally much better tested than security updates, and are much less likely to cause stability problems. This does not mean that service packs necessarily are easier to deploy. They are bigger, and can contain significant functionality changes, as in the case of Windows XP Service Pack 2. However, the differences are likely better known and documented than as is the case with patches. As long as the risk to customers is deemed low, most vendors prefer to hold the fixes until a service pack if one is forthcoming within the not too distant future.

Because this book is largely Microsoft specific, it is worth discussing how Microsoft security updates are shipped. The first way is with a security bulletin as a fix to one or more vulnerabilities in a single component. Security bulletins are posted at http://www.microsoft.com/technet/security. If you have not already done so, you should register to be notified of security bulletins . You can do so at http://www.microsoft.com/technet/security/bulletin/notify.mspx. You can also get security bulletin notification through Really Simple Syndication (RSS). For more information, see http://www.microsoft.com/technet/security/bulletin/secrssinfo.mspx.

The second way a security update is published is through an update rollup . An update rollup is simply a collection of security updates, possibly with other updates included. Some may be previously issued updates, others may be new. Often the update published with a security bulletin is actually an update rollup. For example, all security updates for Internet Explorer are now rollups, including fixes for all previous problems as well.

The third way to get security updates is with a service pack . A service pack is a tested, cumulative set of all security updates, critical updates, and other fixes, such as hotfixes. (A hotfix is a fix for a nonsecurity issue reported by an individual customer.) As mentioned earlier, service packs may also include security fixes for issues found internally to Microsoft during the production of the service pack. When a service pack is published, the fixes included are documented in a Knowledge Base article.