Why you have to be left in the dark on OS patches
Steve Cassidy examines the twisted logic of security patches
The pace of OS and other updates seems to be going berserk in the first half of 2012. It ought to be a fairly fault-free process these days. After all, there’s a long track record of successful updating stretching back for years. However, on those rare occasions when something does go wrong with an update, it’s shocking how little information is available in the public domain to fix the problem.
Admittedly, my most recent experience of this came from trying to combine 2012 updates with some very pre-2010 software – namely, Windows Server 2003 with VMware Server 2.02 for Windows. It turned out, to cut a very painful story short, that VMware Server for Windows employs MSVCR70.DLL, a commonly found library file that’s scattered all across the Program Files directory tree on the affected server.
We can’t expect reasonable disclosure from those whose products we have bought
After February’s non-optional security update, the access that the VMware server had enjoyed to one of those files in a directory in the PATH environment variable suddenly wasn’t there anymore. Bang, no virtual servers on that machine at the next reboot.
What had changed in this update was a tightening of security, a contingent and unexpected result of someone taking a wider than usual strategic view of how resources should be managed in virtualised environments. This was in effect an edict issued from low-Earth orbit about how applications should henceforth be permitted to access shared resources, which you could sum up as “thou shalt not steal stuff from thy neighbour”.
The technical fix for it – documented as per usual for VMware in a forum thread replete with bad guesses, dead-ends and soapbox rants – was to borrow a copy of MSVCR70.DLL from another directory (I plumped for Java’s), and drop it in alongside the VMware executables. Bingo, the service runs up straight away.
I guess one could argue that VMware should have done what Sun did, and supply its own copy of the file just to be polite. On the other hand, why expect a security environment that’s lasted unchanged for almost nine years to suddenly be broken by an unannounced update?
It isn’t as though this is an isolated incident: I’m still smarting from a client who wanted me to take a look at a mysteriously slow-running LAN that turned out to be caused by another ex-cathedra decision by an antivirus product vendor. It had ignored all preceding settings, and delivered an update set up in full paranoia mode. I have to say that when this eventually came to light I thought “hellfire, why bother putting those ‘don’t scan...’ checkbox options in the software at all if you’re going to throw away the users’ choices and slam on the brakes via a silent update?”
From the other side of the table, when you’re talking to software vendors, their answer is the unanswerable one of “security”. If you believe your software has a security problem that it shouldn’t suffer from, of course you want to fix it. If that security problem is made worse because previously it was okay for users to make a particular decision, but now it isn’t, then the only way to put that right is to overwrite what they decided.
What gets to me is the indifference to informing users about what just happened: how hard is it for the update to open a README file in WordPad on the screen of the machine receiving the update? Very difficult apparently, because any kind of communication or opt-in mechanism gives succour to those bad guys whose malware gave rise to the security hole in the first place. Said bad guys would get a chance to abort the update, examine the patch and learn how to circumvent it, which neutralises the point of the update.
So long as we still have a backlog of older OSes with older vulnerabilities in them, there are enough scenarios that actually do work this way that we can’t expect reasonable disclosure from those whose products we have bought. This is why you should be prepared to trawl through the support forums and newsgroups. The entire nature of the communication channel about such topics has to be oblique, or else the bad guys are going to get the message before that brief window during which the update has some relevance.
So no matter how impatient I get while reading chit-chat in the VMware forums, or sitting through rote answers in the Microsoft Community newsgroups, there is a twisted logic behind it all. The pressure is imposed by the fearsomely rapid pace of attacks that are made on our systems every week, and the miracle is that actually we see these kind of unintended consequences so rarely.