Susan Lauber: Watching the meltdown.

Share Button


I have been watching Meltdown and Spectre unfold from the sidelines. Other than applying available updates, I’m just watching and absorbing the process of the disclosure. This one appears mid way along a long road.

I teach mostly administrators. I teach some developers. I teach those in, or desiring to be in, infosec. I like teaching security topics. I think securing systems requires more people thinking about security from the beginning of design and as an everyday, no big deal part of life. A question I ask with these newsworthy issues is what normal practices can mitigate even part of the problems?  There are two big basics – least privilege and patch management – to always keep in mind. Issues like ShellShock and Venom were mostly mitigated from the beginning with SElinux enabled (least privilege) and WannaCry had little impact on those systems patched long ago when the SMB bug was first found and fixed.

However, in some cases, both exploits and accidents come from doing something that no one else thought of trying. This is why I like open source. There is the option (not always used) for more people trying different things and finding better uses as well as potential flaws. Any type of cooperation and collaboration can be the source of some of these findings including pull requests, conference talks, or corporations working with academic research projects.

Spectra and Meltdown are not the first bug of their kind, nor the last. Anything that grabs or holds more information than is requested – such as cache or speculation – is bound to eventually grab and expose something it shouldn’t. Or allow some type of injection. I gave some kudos to the team getting the credit for this discovery and got some push back from a friend defending another friend that gave a related talk at a conference in 2016. Maybe not enough credit is given to those that speculated (pun intended) on this type of problem in the past. This timeline lists several and some retweets from people I trust to be smarter than me in this topic point to ideas even older.

Speculative execution considered harmful in 1995: “Prefetching may fetch otherwise inaccesible instructions in Virtual 8086 mode.” https://t.co/KRMCEAfZgX pic.twitter.com/r62roI1Q6H

— Trammell Hudson ⚙ (@qrs) January 8, 2018

Something much simpler than what you did 🙂 See below. This is part of the work Rafał Wojtczuk and I did back in 2010. It’s no longer under an NDA, so can paste here. We’ve never published it since we had no working attacks… pic.twitter.com/i5xUQbgbv3

— Joanna Rutkowska (@rootkovska) January 4, 2018

The Google Project Zero team is getting the recognition because of a variety of pieces in a big puzzle. Right place, right time. Privilege from the backing of a large company. Their use of the embargo and disclosure process working across the industry. A new proof of concept and published paper. Indications of ways to exploit it at scale. A mitigation. It all comes together and suddenly more than just the researchers realize the scope of the risk that has been taken. Intel is getting more than their share of the blame too when people recognize a company name faster than a general concept or part of a computer. And, yes, in some cases there is also too much fluff and fear in the reporting.

The embargo and disclosure process is pretty interesting too. I sat in a talk a couple of years ago about how a large company deals with this in the open source world and Mike Bursell has a post with thoughts about it again in reference to this case. I actually had an idea something big was coming from the combination of noise and speculation about patches being submitted and who was NOT talking about them.

We are still discovering the full impact of the CPU design decisions made. Sure, they are serious, especially as more people are able to automate attacks against the vulnerability, but they are also nothing to panic about. This is not just an Intel problem. It is a market driven quest for more power with less money and despite various risks. We are all to blame. Apply the patches, monitor the impact, invest in the next generation of inventors and inventions. In other words, business as usual.

The choices were made in favor of optimization, so will things be a little slower now? Probably for many people, but not everyone. Will we get over it? I would think so.

What will happen in the long run with the latest news? I predict many people will choose performance over security. I predict a few years from now when someone finds a scalable way to exploit one or more of the variations, people will have forgotten that they should have updated bios, firmware, and kernels today. If we are lucky, they will have the latest patches already deployed and just need to make some configuration changes. But when has luck worked out as the best security practice?

Links I have collected helping me to understand:

SANS Institute webcast.

Watch the #Meltdown and #Spectre – Understanding and mitigating the threats – WEBCAST with @MalwareJake #DFIR #Threathunting via @YouTube @SANSEMEA @SANSAPAC @SANSInstitute @SANSPenTest   https://t.co/riftmzDNVs

— SANS DFIR (@sansforensics) January 8, 2018

#Meltdown & #Spectre are 2 security issues that threaten nearly all computers & mobile devices. Find out where they came from & what’s being done about them: https://t.co/K4udZdOTWa pic.twitter.com/Q6H1nSql5z

— Red Hat, Inc. (@RedHatNews) January 6, 2018

Fedora Magazine KTPI overview.

OpenStack, What you need to know.

Project Zero technical overview.

xkcd

My favorite analogy thread – the library comparison – (more were rounded up here).

Here’s my layman’s not-totally-accurate-but-gets-the-point-across story about how  #meltdown & #spectre type attacks work:

Let’s say you go to a library that has a ‘special collection’ you’re not allowed access to, but you want to to read one of the books. 1/10

— Joe Fitz (@securelyfitz) January 4, 2018

-SML

Powered by WPeMatico

Share Button