The Spectre of Chip Meltdown

The latest big-time cybersecurity scare is the discovery of vulnerabilities, named Spectre and Meltdown by researchers, in many computer processors from Intel and others, which open affected processors up to exploitation by hackers who can, as I understand the situation, use those vulnerabilities to access data across user accounts.

But, first, a little history … I wrote a column on “Running ‘Afoul of the Flaw’” in the February/March 1995 issue of Securities Industry Management Magazine. Those of us who have been around IT for a while will recall that we became aware of a flaw in Intel’s Pentium chip in late 1994. The “bug” caused miscalculations to occur without user’s knowledge, potentially leading to seriously erroneous results. That was some 23 years ago, well before the proliferation of the Internet and the advent of modern cyberattacks. The surprise is that we have heard of so few reported chip flaws since then, given the huge increases in power and complexity of modern computer processors. Perhaps they exist, but we are just not aware of such unknown unknowns.

At the time, I noted that it was generally held that flaws are unavoidable in complex manmade devices, and that computer systems are fallible. I concluded that: “The only answer is to spend the extra time and money to build in safeguards that will anticipate that the systems won’t work perfectly every time.” I suggested that we follow Nature by building tolerance, redundancy and resiliency into computer systems. However, times have changed, and I would certainly now add the monoculture issue to the debate. In 2003, the report “Cyber Insecurity: The Cost of Monopoly” by such luminaries as Dan Geer, Bruce Schneier and the late Becky Bace, and others, raised concerns that the dominance of certain products, such as those from Microsoft (at the time), raised the likelihood of far-reaching security breaches because a single exploit would affect high percentages of installed systems. You can still find a version of the report at

There have been a number of instances of market dominance leading to Internet-wide vulnerabilities, even with open-source software such as from Apache, and the risks only increase as the number of systems proliferates exponentially.

Second, I worked for a financial firm that processed the accounts of a large number of broker/dealers and one of the greatest concerns of customer firms was the possibility of one firm being able to access anther firm’s customer information. Even if it was a matter of firm A seeing some of firm B’s customer data, firm A would immediately have great concern that others may have access to their data. Despite Herculean efforts to test for such a possibility, occasional unauthorized access to others’ data would still happen. And the reasons in such cases were often complicated and difficult to analyze.

Typically, a breach of this type was the result of a particular one-in-a-million situation where a user went through an unusual sequence of interactions with the system and, in one example that I recall, the software did not initialize a buffer within the system so that the new user was able (unintentionally) to access a prior user’s data. In this case, it wasn’t as serious as it might have been, since the data were so-called “administrative messages” which did not reveal sensitive account information. Nevertheless, it did show that exhaustive testing, orders of magnitude greater than regular testing (and hence virtually impossible to justify) might have caught the error. It was this, and other similar examples, that resulted in my writing “The Need for Functional Security Testing,” in the March/April 2011 issue of STSC CrossTalk: The Journal of Defense Software Engineering.

Fast forward to today’s processor issue. The lessons are clear. We must explore the possibilities of diversity in the hardware and software products that we use. And manufacturers must engage in much more functional security testing. The problem isn’t going to go away. In fact, it is likely to get much worse over time. We need to act now!

Post a Comment

Your email is never published nor shared. Required fields are marked *