A Disaster In The Making
This is not good:
Obviously, for those of us with an ‘interest’ in such matters, the downsides of the Agile paradigm have been all too apparent for all too long now: quite apart from any inherent shortcomings there might be to the approach of releasing early and often, with the view that issues can be patched as time goes by rather than waiting until a fundamentally stable and secure solution has been developed … there’s the little matter of when the metal of development is met by the pedal of a management interested in financial reward rather than understanding what it is the business actually does, let alone what constitutes best practice in its field.
Security is not something you can bolt on to an inadequate solution later. Yes, you can give people sauces, relishes and what-have-you on the side to make their meal more palatable, but they won’t extract the excessive spices from a dish that will subsequently necessitate an unpleasant trip to the bathroom.
Routers, switches, firewalls, modems and the like that have such faulty firmware are a disaster already happening, never mind in the making — when was the last time you though to even reboot yours, let alone update the firmware on it? Can you update it, or is that out of your control? What even is the firmware and who supplied it? Would you know how to find out? Can you find out or is that information undocumented? How would you find out?
Much is made of the ‘many eyes’ theory of security (and occasionally privacy) by OSS evangelists but, as a number of shocking flaws over the years have shown, that seems to be observed more in the preaching than in the practice and, whilst on this occasion it does indeed seem to have been vindicated, if you pay attention to the detail, you can’t help wondering what might’ve happened, if Donenfeld hadn’t read that mailing list … or that particular mailing list hadn’t featured a mention of the project in the first place — another Heartbleed level failure no doubt, affecting everyone using any operating system on any computer by any manufacturer, who, if not using a Netgate product themselves, would inevitably end up sending/receiving data to/from others who were.
The approach seemingly taken by the FreeBSD community, of a community project with a flat (or even absent) hierarchy, is a lovely ideal but, in practice, can result in quite alarming (to outright scary) outcomes … particularly in the case of something like the BSDs, which are famously ‘secure’ and used by the likes of Netflix and WhatsApp — as long ago as December 2017, reported bugs were still unpatched six months later, many of which had been present in the code for a decade or more:
… but, in the meantime, Netflix will be transmitting customer data across systems that … sooner or later … interface with BSD and, if you’re in India, for instance, it’s highly likely that you’ve made purchases over WhatsApp too, putting yourself at an even greater risk of identity theft, or having your bank account emptied.
You only have to look at the number of projects, products and services Google, with all it’s money and manpower, discards to see the risks, if not outright dangers, of an approach whereby developers work on what they’re interested in until they lose interest, lack the resources to do so, or face life decisions that mean they no longer have the time for them. Consider those working on stuff freelance, with no backing beyond their own means … if no sponsorship is forthcoming for their particular project then you can expect that it isn’t a particularly popular one and shouldn’t expect a huge number of eyes to be on it in the first place.
In the case of something like Bash (Bourne Again Shell) … the default cli (command line interpreter) on most distributions of Linux … the fact that the project was maintained by one person at any given time, meant that the Shellshock bug went undetected for twenty-five years (a quarter of a century, to put it in perspective), … practically right from the very start of the project.
With no structure in place to ensure that the dull tasks of debugging and refinement are pursued, developers with no-one to whom they are answerable are not obliged to do so and, as like as not, rather than engage in the boring task of squashing bugs, will jump onto developing something new and/or ‘shiny’ instead.
Make no mistake, something as seemingly obscure and dull as this particular case, despite overtly validating the ‘many eyes’ approach, should be a wake-up call for everyone and catch your attention very decisively. This time, the problem was caught. Next time, we may not be so lucky … and if you aren’t using the problem product or service yourself, others are — eventually, some of your communication will pass through one of them … and, if that particular product is compromised then so will your data be.
Our world is controlled by computers. It has been for a very long time already and is only becoming more so by the day. From the hole in the wall, from which you withdraw cash, by way of the mobile communications device in your pocket, the car you drive, the bell outside your front door, the corporate systems your employer relies upon to do business and pay you, the logistics chains between the various entities that make it possible to even buy things in shops, let alone online, to the tractors driven by farmers growing the food you eat and the machines that get the milk from the cow for you to pour on your cereal … your entire life depends upon computer hardware, firmware and software. I recommend, therefore, that you pay attention to what goes on in the world of IT — it’s not often exciting, but it’s all too frequently lifechanging.
As ever, I recommend looking at the reader comments as well as the article itself — you’ll find further food for thought and (possibly) education there.
