Often customers run offline systems and claim that such machines do not need updates since they are offline. But this is a fallacy: updates do not only close security holes but also deliver bug fixes – and they can be crucial.
Background
Recently a customer approached me with questions regarding an upgrade of a server. During the discussion, the customer mentioned that the system never got upgrades:
“It is an offline system, there is no need.”
That’s a common misconception. And a dangerous one.
Many people think that updates are only important to fix security issues, and that bugfixes are not really worth considering – after all, the machine works, right?
Wrong!
Software is never perfect. Errors happen. And while security issues might be uncomfortable, bugs in the program code can be a much more serious issue than “mere” security problems.
Example One: Xerox
To pick an example, almost each company out there has one type of system which hardly ever gets updated: copy machines. These days they are connected to the internet and can e-mail scanned documents. They are usually never updated, after all it just works, right?
In 2013 it was discovered that many Xerox WorkCentres had a serious software bug, causing them to alter scanned numbers. It took quite some weeks and analysis until finally a software update fixed the issue. During that time it turned out that the bug was at least 8 years old. So millions and millions of faulty scans have been produced over the years. In some cases the originals were destroyed in the meantime. It can hardly be estimated what impact that will have, but for sure it’s huge and will accompany us for a long time. And it was estimated that even today many scanners are still not patched – because it is not common to patch such systems. Offline, right?
So yes, a security issue might expose your data to the world. But it’s worse when the data is wrong to begin with.
Example two: Jails
Another example hit the news just recently: the US Washington State Department of Correction released inmates too early – due to a software bug. Again the software bug was present for years and years, releasing inmates too early all the time.
Example three: Valve
While Valve’s systems are often per definition online, the Valve Steam for Linux bug showed that all kinds of software can contain, well, all kinds of bugs: if you moved the folder of your Steam client, it could actually delete your entire (home) directory. Just like that. And again: this bug did not happen all the time, but only in certain situations and after quite some time.
# deletes your files when the variable is not set anymore rm -rf "$STEAMROOT/"*
Example four: Office software
Imagine you have a bug in your calculating software – so that numbers are not processed or displayed correctly. The possible implications are endless. Two famous bugs which shows that bugfixes are worth considering are the MS Office multiplication bug from 2007 and the MS Office sum bug from a year later.
Example five: health
Yet another example surfaced in 2000 when a treatment planning system at a radiotherapy department was found to calculate wrong treatment times for patients and thus the patients were exposed to much more radiation than was good for them. It took quite some time until the bug was discovered – too lat for some patients whose
Conclusion
So, yes, security issues are harmful. They must be taken serious, and a solid and well designed security concept should be applied. Multiple layers, different zones, role based access, update often, etc.
But systems which are secured by air gaps need to be updated as well. The above mentioned examples do not show bugs in highly specific applications, but also in software components used in thousands and millions of machines. So administrators should at least spend few seconds reading into each update and check if its relevant. Otherwise you might ignore that you corrupt your data over years and years without realizing it – until its too late.
/home/liquidat 
I am with you in the terms, that software gets mostly better in some way and that bugs in mission critical software, that may have some deadly outcome (health care, autonomous cars, etc) should be fixed of course. I am myself a rolling release distribution user and therefore I also like to be at the top of the progress and benefit from the cool new things, that come along.
However, I do not think that you analysis is very practical for many end users. Your post completely ignores, that updates can also make things worse, especially feature updates. And well its the new trend to abandon this longterm supported software and go continuous.
From an administrative point of view I also like to have many small evolutionary steps. I, as a software developer can identify things that go wrong early, do not have to deal with a large portion of problem at once if i do a huge update every 5 years or so and I am able to solve the small update problems myself. Some end users with other professions might need to call the support.
With each update, you will need to adapt to interface changes and technical changes. This often happens in a more regular way, than the standard user is benefiting from. If you use some application 10 minutes a week, you are not willing to learn another an hour about the changes from new updates every few month. Well, you should not blame the software for bugs, if you use a several years old version. If there is something that annoys you and it is fixed in a new version, well try the new version, but otherwise, I am not so sure? Some changes might also break compatibility with some other software. All this dependencies between your software components will very likely give you some headache some day and you are forced to move on to other solutions for the same tasks.
Of course again from an administrative point of view, it might be very troublesome to move your data if you are using a software that is dead for many years and the new software cuts of some migration path. I am not saying there are not situation in which you should go forth.
However, here some example:
In the company of my father we are still running some software form the the 80th to run some physical tests on some soil probes. It runs on top of DOS and Turbo Pascal. Well you might say we should have moved on some time earlier, but this would have meant, that we had to buy some new iterations of measurement hardware (about 20k$ each) to get support for new operating systems and software, we would have to configure, lets say 5 iterations of completely different software as the old one has died out and face the individual problems of each of them. The data is saved as csv, still readable today. After some years of using a software, you are sure that nothing is going wrong in a way you do not know. You have adapted your work flow around existing problems and even if it is not the perfect workflow it might be just enough. It just does what it should since 30 years. And i would bet, that you cannot do reasonable faster with a software from today. There is no pressure for more.
Hej Till,
thanks for sharing your thoughts with me, especially in such a detail! =)
You are right that I somewhat neglected the fact that updates can make things worse. In the end I did suggest that administrators should not apply all updates, but at least check them even though they feel safe. That indirectly covers that things can get worse, I think.
But you are right – especially given the mobile world where apps sometimes drop features this can be pretty bad for end users. And if oyou update across versions you for sure will have dropped features, a different UI or at least different work flows in the software, etc., which all brings in new chances for errors and new bugs.
So next time I should take the time to at least write one or two more sentences about the target audience I had in mind: enterprise admins and software which has a long life with minor updates which at least are not supposed to drop features or rip the UI apart.
And the post was indeed a bit of provicative, since most often admins just tell me they never update – and don’t even think about it. As long as I get them starting to think about it, a lot is won.
Last but not least, regarding the mentioned example of the Turbo Pascal software: there are surprisingly many examples like that out there even in the big enterprise IT environments, often at critical cores of the entire business. Let’s just hope that there are no hidden bugs which only trigger after 32 years or something 😉