Do You Always Need to Install Software Updates?

Monday, September 12, 2011

Cor Rosielle


In general the installation of software updates it is considered as a good manner to keep a system safe. Research has been done to determine the impact of installing software updates or using anti virus software on the presence of malware.

Otherwise than you might expect, the results (presented at DIMVA 2011 in Amsterdam, The Netherlands) showed there is no significant difference in the amount of malware on patched computers compared to unpatched computers.

It is about time to think if it is wise to blindly install software updates.

The idea that installing software updates is good for security is strengthened by laws and regulations. Such compliance rules often require that security updates are installed shortly after they become available. The idea is further amplified by security experts who tell this is necessary. Alas this is only "parrot talk" where they don't rely too much on their own minds.

Further, if you experience problems with some software, one of the first questions of customer support is if you installed all available updates. If not, then you have to install the patches first to see if that solves the problem. If the problem remains, you are very welcome to call them again.

But what if we do use our brains or do some research for facts, would we find indications that blindly installing patches adds to the security of systems?

There is always first a vulnerability and after that, often many months later, the vendor has a patch available. The fact that the details of the vulnerability were kept secret al the time, does not mean no one used or misused that vulnerability on your system. The vulnerability was present since the product was installed and there is no reason to assume that absolutely no one abused it. 

After the patch becomes available the whole world can know about the weakness and often a working exploit is available as well. So between the release and the installation of the patch, the system is even more vulnerable. 

Sometimes software does not work anymore after patch ing. As a result the update can end up in a catastrophe. Do you remember how to update of Anti-Virus software in April 2010 broke millions of PC's worldwide? It was reported that  even patients from intensive care units had to be evacuated because critical life functions could be no longer monitored. And then there are people who call this safe. A little googling provides many such examples.

Unlike the above, it also happens that warranty is void if the software or the configuration of a custom installation is changed after delivery of the project. In my personal experience, this occurred in SCADA environments and telephony servers. This was one of the causes why the last Windows 3.51 server I managed was phased out not earlier than 2006. This service provided by this system was not otherwise available.

Under ideal circumstances, the patching of servers is done in no time. Login, install the patch and ready. But the circumstances are not always ideal and it can be a lot of work. If it is not allowed to interrupt the service that the server is providing, the patch has to be installed at ungodly hours.

And because we do not like to work at ungodly hours, we save the patches and install them all at once. And if the patch has to be uninstalled for an unforeseen reason, it can become really exciting, because after uninstalling you don't always end up with a functioning system.

Perhaps this is not a surprise when you realize that the patch is supplied by the same supplier that originally delivered faulty software. And if they can't deliver proper software in the first place, then why should we expect them to deliver error-free patches that can be easily installed or uninstalled without errors?

And it gets worse. Frequently an update doesn't only fix a flaw in existing functionality, but it also includes new functionality. Something you seldom asked for. Even if that functionality is desired, then it frequently leads to unacceptable unavailability of the system.

C2000 is an emergency communication system for Dutch police, firefighters, ambulance and other rescue services. Every few weeks the system is unavailable for a shorter or long longer period of time to install updates. Sometimes the system is even unavailable for one and and an half hours, while it should be available 24x7.

When updates are installed blindly and routinely, you fix imperfections you never even knew existed or you fix a vulnerability in a component that you're not even using. These are two examples where an update is installed without any need for it, but using other words.

Not implementing patches may also save you a lot of money. When I bought cheap ink cartridges, the result was disappointing. The next time I bought the expensive cartridges from the printer manufacturer again. When the salesman offered me cheap cartridges again some time later, I told him about the disappointing results.

He then explained to me that this manufacturer provided updates for its printer drivers to Microsoft. This way the manufacturer could control the quality of prints made with original cartridges or alternative cartridges. After I didn't accept updates for the printer driver for about half a year, the cheap ink cartridges gave good results. And because I still don't update my printer drivers to "profit" from enhanced quality, the inexpensive cartridges still works.

The automatic updates of software can easily be attacked. Seldom the updates are downloaded using secure protocols (https) and therefore it is relative simple for a hacker to inject his own software if a victim downloads an update and installs it. There is even software available to do this, so this attack is now within reach of script kiddies too.

The facts speak for themselves. There are some snags to automated downloading and installing updates. Therefore, we should think more often about whether an update should be installed at all. It helps if you know what the operational security level is of the system to patch (Security Attack Surface Metric or rav, see OSSTMM 3 -

This not only check if the software is known to have a known vulnerability, but all security controls are taken into account. It will show that a patch is not always necessary, because other security measures to prevent the vulnerability to be exploited. And if system managers make well informed decisions and decide not to install an update, it would adorn auditors as they go along with these thoughts and not stick to rigid rules of thumb and so-called best practices. 

Of course, it also happens that a patch is really the best solution in a given situation. In that situation it could be decided to install the patch. We do this by first downloading the update (via https) and check the integrity of the update and then install the update through the vulnerability management process.

So to maintain the safety of a system it does help to know if a system has a vulnerability.  And therefore vulnerability scanners do certainly have an added value. Even if it turns out that a system has a vulnerability and no patch is available, other security controls may be considered to reduce the likelihood of successful exploitation. 

Whether it is necessary or wise to install an available patch or not is an individual assessment for each company. And to determine whether or not this is sensible, we can not blindly and without thinking install just about any available update. No, to determine that we must use use our brains. Ouch!

Bottom line: more often should be decided not to install software updates. It makes sense to protect systems using other controls. Only when the patch is the best solution, then you choose to patch.

Possibly Related Articles:
Compliance Software Patch Management OSSTMM Network Security Update
Post Rating I Like this!
Anders Reed-Mohn What research are you referring to? It's hard to consider what you say without seeing what you are referring to.
And what research have you compared it too?

It also seems to me you are comparing patching "ordinary" systems to patching critical systems. I'm not convinced a risk analysis will give the same result for those.
Cor Rosielle The research is done by Gregor Maier, Anja Feldmann, Vern Paxson, Robin Sommer and Matthias Vallentin. The research is mentioned in their report "An Assessment of Overt Malicious Activity Manifest in Residential Networks", which was presented during the "Eighth Conference on Detection of Intrusions and Malware & Vulnerability Assessment", held in July 2011 at the university in Amsterdam, The Netherlands.

I don't say to never path a system, but to patch if it is the best solution. Indeed there is a difference between patching "ordinary" systems or patching critical systems. If you patch critical systems you have to be more careful than patching "ordinary" systems, because you can't afford negative impact of a failing patch.
Roland Ritthaler Some years ago, maybe 15 or 20, there were two rules for stable systems:

1. Don't install a update you don't need.
2. Don't fix a bug you don't have.

Whenever a programm asks my firewall to "call home", looking for updates, i think about these rules and the new - yet unknown - risks the update will bring to my systems instead of the risks i already knew. So each update is a risk based decision.
Alex Kosyak Right. Thinking that patching is a silver bullet is too naive, of course - but, other things being equal, you are better off after applying security patches, aren't you? Yes, you need to test them before you apply them to your critical production systems - do not apply them blindly.

Basically, I agree that not every patch is strictly necessary - but one needs to use his/her grayware to figure out which are the most important ones, true. Unfortunately, knowledgeable grayware is a scarce resource, and if available is likely to be already engaged in a myriad of other activities. So you will likely to hear, at your workpace, "just apply those patches, will you?"

Another problem is the division of labor (not to mix up with separation of duties): security professionals are usually not willing to take the burden of responsibility on their shoulders and say, for example, that patch X identified as missing and high risk by the VA scan is actually a low risk one in a particular case (as it often happens), because it is THEIR JOB to promote security. If they are wrong (and every one of us is wrong at times), they risk their career. If they are right, they need to document their risk assessment so that the next audit don't slap them on the wrists - and documenting risk assessment for a patch might take more effort than installing it. On the other hand, the IT people who have to do the work installing and testing those patches, are also more inclined to do what they are told to do by "security" rather than argue. Sometimes they do argue, of course - but that usually leads to escalations and they typically lose in the end.

So, just install those patches.
Pete Herzog But Alex, the other things aren't equal so you're not better off applying security patches. That's the point of the article. Not all security patches are useful to everyone. Not all security patches have protection of the customer in mind- some, like those that drive DRM into our machines, may be for the protection of content providers, or, as Cor mentions, restrict us to using specific printer cartridges.

The other problem you refer to, the division of labor, is one that is solved with knowledge. Installing and testing a patch takes resources. These are resources which can better be used to improve business function rather than chasing down all the patches like butterflies. Knowledge that there is a right decision that saves resources is generally welcomed if it can be properly proven. Of course this can't help those who refuse to change. But then they won't be around along anyway....
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.