Happy New Year 2018 – Let the Dumpster Fires Begin

Just three days into 2018, two massive security warnings were issued for Meltdown and Spectre. About those names – for an industry that claims to hate FUD, we need to work on this. But all kidding aside, these are perhaps the biggest inherent vulnerabilities to be brought to light that I am aware of. For good reason. When almost every device we use in our online and connected lives contains the problem at hand, it’s a top-tier event. Rather than jump on the “sky is falling” bandwagon, I chose to wait things out and read all that I could. There are far more experienced and knowledgeable people who have been weighing in on this from the start, and I will share links to their excellent insights and explanations. Also, as dust settles we can seee things more clearly, which is very relevant when dealing with a situation as massive and impactful as this. More details come available; facts are verified; information about what to do is tested and shared. Worth waiting for given that there was no immediate fix and panic is never a solution.

Here is the simplest breakdown of what both are by Daniel Miessler. What everyone is worried about is that both of these enable attackers to access information and processes that we had all thought were inherently secured, like privacy keys we use to protect our data. Daniel lays it all out here:

Both Meltdown and Spectre allow low-privilege users who execute code on your system to read sensitive information from memory via Speculative Execution. The basic concept for these two attacks is that you should consider secrets to be attackable any place you’re allowing someone else’s code to run on an affected system.

In Meltdown that means “any secret a computer is protecting (even in the kernel) is available to any user able to execute code on the system.” (Miessler) Spectre is worse in that it “works by tricking processors into executing instructions they should not have been able to, granting access to sensitive information in other applications’ memory space.” (Miessler)

What I have been listening for is how this may impact Cloud computing, which we only think we understand, and we need to remember is just somebody else’s server. Jerry Bell has written a piece on his blog, “Thoughts on Cloud Computing in the Wake of Meltdown”. He happens to be one of my go-to sources as part of the Dynamic Duo on the Defensive Security Podcast. First, the good news. As managed service providers running largely out of datacenters, these operations will have likely been told to patch ahead of most, and done so in the best interests of running their business. As well, since datacenters are large organizations managing many clients, they will be using automation to help the patching process. And patching is complicated, especially when it comes to these critical issues.

And that brings us to the not so good news. Patching virtual machines isn’t always straightforward or successful.

spec2 spec1

As Jerry presents:

Meltdown provided an apparent possibility for a guest in one virtual machine to read the memory of a different virtual machine running on the same physical server. This is a threat that doesn’t exist on private servers, or is much less concerning for private cloud. This vulnerability existed for many years

And then there are performance issues. Interestingly, as Jerry points out, not as hard to mitigate on cloud as they would be for physical servers.

One of the big downsides to cloud therefore, seems to the risk of a sudden change in the operating environment that results in higher cloud service costs. As problematic as that might be, firing an API to increase the execution cap or add CPUs to a cloud server is logistically much simpler than private physical servers experiencing the same performance hit and needing to be replaced, which requires the arduous process of obtaining approval for a new server, placing the order, waiting, racking, cabling, set up, and so on.

Based on this, and what has been occurring across 2016 and 2017, I predict we will see more of these events where something we did in the past comes back to “haunt” us, from a time when we did not have any idea of how technology would develop. We are now uncovering what lies beneath the surface of frameworks we rely on that others laid down before us. Simon Segars is CEO of ARM Holdings, which designs mobile chips. He warned at CES 2018 in Vegas last week that we need to expect more of these discoveries. He states one of my chief concerns here:

“The reality is there are probably other things out there like it that have been deemed safe for years.. Somebody whose mind is sufficiently warped toward think about security threats may find other ways to exploit systems which had otherwise been considered comletely safe.”

We don’t know what we don’t know unfortunately in this case, so we need to be prepared for similar discoveries. More importantly, we need to be ready to assess, then share the information in a controlled and constructive fashion while we mobilize immediate and long term responses to the event. My watchword now is “prudence”, both in terms of patching, and then in terms of vigilance as we watch over all our systems with new eyes and insights. Haste makes waste. Because as time has borne out, and is once again, patches can go sideways very badly. Whether you brick a device or you brick an enterprise, both outcomes are severe.

UPDATE ON PATCHES

Per Steve Ragan’s piece in CSO Online, Microsoft has suspended Windows security updates related to this issue on systems with older AMD CPUs, after a documentation mix-up led to the systems being unable to boot after patches were applied.

In order to “prevent AMD customers from getting into an unbootable state,” Microsoft has temporarily paused sending the following Windows updates to devices with impacted AMD processors: