Heads-up on an old but very big security hole

Someone here current in the software industry might have a handle on what’s affected among our investments. It’s also an opportunity for companies to gain customers by publicizing that they’re free of this hazard, or to be the ones fixing the problem. And a proactive AI tool to find new vulnerabilities would also be very welcome. This kind of design has started to gain traction in virus detection vs. the usual “virus signature” method.

I’m getting even more skeptical about the “move fast and break things” ethos. That’s not exactly how civil engineers design bridges, and it shouldn’t be how software engineers write the code that affects more and more of our life.

https://www.wired.com/story/urgent-11-ipnet-vulnerable-devic…

Nearly two decades ago, a company called Interpeak created a network protocol that became an industry standard. It also had severe bugs that are only now coming to light.

Today Armis, the Department of Homeland Security, the Food and Drug Administration, and a broad swath of so-called real-time operating system and device companies disclosed that Urgent/11, a suite of network protocol bugs, exist in far more platforms than originally believed. The RTO systems are used in the always-on devices common to the industrial control or health care industries. And while they’re distinct platforms, many of them incorporate the same decades-old networking code that leaves them vulnerable to denial of service attacks or even full takeovers. There are at least seven affected operating systems that run in countless IoT devices across the industry.

7 Likes

I’m getting even more skeptical about the “move fast and break things” ethos. That’s not exactly how civil engineers design bridges, and it shouldn’t be how software engineers write the code that affects more and more of our life.

I’m not sure exactly what you are referring to here in terms of software, but it should be noted that there are some big differences between software and civil engineering. In civil engineering the goal is typically very clear up front and the only question is how to fulfill that goal … what type of bridge to use, for example. While requirements can change over time … increased traffic flow, desire for a bike lane, etc. … even those changes are ones that one can often anticipate for a significant future.

With software, on the other hand, the goal is often very unclear up front … I think you would be surprised at just how different the original stated need and the actual software that will fulfill the requirement can be. Moreover, the requirements often change rapidly and substantially in quite short periods of time. Yes, a good analyst/designer with strong industry knowledge can often build in a lot of flexibility which can respond to these changes more readily, but one can be confident that the requirements will change enough to require a change in the software and probably in not very long.

So, some of the modern software techniques in which one codes something quickly and puts it in front of the customer are intended to recognize the difficulty of clearly identifying the requirements up front. By frequent interaction of the user with a partially completed system one discovers what is missing or misunderstood without investing a huge amount of development that then needs to be substantially reworked. Rest assured that old network protocols and operating systems like those referred to here were not developed by these newer agile techniques, but rather were done with the old fashioned waterfall approach. The error was in testing insufficient to discover the bugs, although the fact that they have persisted this long probably means that the bugs did not impact the vast bulk of normal usage.

7 Likes