6

Let me clarify two methods of patching softwares and then I will go straight to the question:

I am using both MAC OS X and Windows and different mechanisms of these two famous operating systems in handling software updates are interesting to me.
When an update is available in OS X, usually a complete renewal of the troublesome part is available and it seems to me that it completely renews that part, but when there is a hotfix for windows available, this hotfix is usually so tiny (in comparison with what we download from apple site).

I am wondering about cons and pros of such mechanisms (toward security goal of that software) and I don't care about who is right or wrong, I need a comparison of security affects that these patch management techniques can cause and the amount of labor and side effect in different patch management strategies (If it is so broad, a reference may suffice to give me a clue on how to start).
{Please provide constructive answers and avoid blaming any software vendor esp those two mentioned above in any part of your answer. This is the policy of this forum as long as I am concerned. Thanks}

Improve this question

2 Answers 2

Reset to default
4

So essentially this comes down to whether the patch is delivered as a set of replacement files, or a set of "binary diffs" to be applied to the existing files.

  • It's usually easier to update an arbitrary earlier version of the software from the replacement files. For example if you have 1.0.2 of a component and the patch delivers 1.0.7, with the replacement you just go ahead and install that. With diffs you must (often) go via 1.0.3, 1.0.4 etc. I remember Solaris' patching mechanism having this interesting feature (and having to install each part manually, before PatchPro was released).
  • It's usually quicker to download the binary diff updates.
  • A replacement component install is more likely to succeed if the original files have been modified somehow. However, you shouldn't be relying on the patch manager as your integrity checker anyway.

In fact, in my experience the "security" of a patch comes down not to the installation mechanism (except that automated usually beats manual), but to these two things:

  1. Most importantly, the latency between availability and installation of the patch. See, for example, the Slammer worm.
  2. The amount of testing done by the vendor before distributing the patch.
Improve this answer
3
  • In a small order, this could be right but assume an operating system as vast and user-friendly as windows or others, could this update affect other sides of operating system (i.e., unwanted side effects)?
    – Yasser Sobhdel
    Commented Apr 19, 2011 at 8:23
  • @Yasser that comes down to my point 2: the amount of testing. Patches occasionally interfere with third-party applications too, but it's usually the change in behaviour of the system after the patch is applied that causes issues rather than the mechanics of applying the patch.
    – user185
    Commented Apr 19, 2011 at 8:45
  • 3
    @Yasser - just to add to @Graham's point. 1 and 2 are often incompatible: the vendor wants to test as much as possible to avoid disrupting systems, but unless a critical patch is deployed rapidly, attackers could cause major disruption. The result - a trade-off. My advice to everyone is to maintain a test version of their production environment and fully test all critical patches there as soon as they become available - then rollout to your live environment once you have confirmed the patching will work successfully for you.
    – Rory Alsop ♦
    Commented Apr 19, 2011 at 9:29
1

In principle there is no difference between patching by installing the entire new binary vs. patching by diffs, either way you wind up with the same target state assuming both are implemented correctly.

Patching by diffs is (usually) going to be more efficient in terms of network bandwidth but (if you are implementing patching for your own software) is also going to be more complex because you need to cater for all the different old versions of your software which the client may have (in addition to all the old versions of the data formats, if these have changed).

One could also argue that more complexity in diff patching means more likelihood of implementation mistakes, some of which will be security relevant, and probably most of which would result in a system that doesn't work.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .