A Look at Meltdown and Spectre

Meltdown and Spectre have been predictably making waves in the industry, and the vendor responses have been scattered and, in some cases, haphazard. The latest patches from Intel cause increased system reboots; Microsoft had to halt patches for AMD systems, as systems were rendered unbootable. Ubuntu Linux has also had a patch reverted due to systems being unbootable. The overall fix is changing the processor architecture, which likely won’t happen for a number of years.

As a brief introduction to these vulnerabilities, Meltdown and Spectre are two different attacks leveraged against the intended functionality of modern processors. Meltdown can be used broadly against a wide range of processors from different vendors, and its main functionality is to potentially read kernel memory from userspace. Spectre is much more targeted, and focuses on leaking data between or within processes. The key point to understand about these vulnerabilities is that they are information disclosure vulnerabilities that can enable processes and applications to access information they otherwise shouldn’t be able to: user-mode applications can access privileged information in the kernel and throughout the operating system.

As a Palo Alto Networks partner, EITS has been closely following their response to the bugs. As with most vendors, the main recommendation has been to focus on patching your servers and endpoints as you can, and if there are any specific attacks that can be mitigated, they will provide security content to address this as they can. Palo Alto Networks' Traps endpoint product has also been noted, like other AV solutions, to not be capable of stopping these attacks, as these are kernel memory reading vulnerabilities that do not cause code execution. That being said, Traps is one of the most well-equipped products at mitigating attacks in general, and Meltdown/Spectre still rely on local privilege and deployment mechanisms such as malware.

Microsoft has made a significant change in their patching process moving forward in relation to AV compatibility. Historically, Microsoft has called out any vendors that caused issues with patches they deployed, and, as is expected in this industry, vendors have been quick to point out issues with Microsoft. As of the January 3rd patch, however, Microsoft deemed it important enough to require A/V vendors evaluate their products for compatibility, and then set a registry key on impacted endpoints.

If a machine does not have this registry key, they will no longer receive security updates from Microsoft through Automatic Updates. For organizations leveraging deployment solutions to deliver their patches, there should not be any impact. What makes this a bit more complicated for everyone else is that many vendors have chosen to not automatically set this registry key, including Palo Alto Networks Traps (note: Palo Alto Networks is working on an update to do this and is expected soon.)

EITS recommends evaluating any patches relevant to your systems thoroughly due to these documented concerns. You can find more information at the below links:


Customer Advisory from Palo Alto Networks


The Register: Meltdown/Spectre Week Three


Overview of Impact by Intel

Happy Streams - Paul's Security Weekly #543

Diana Kelley and Ed Moyle of Security Curve join us for an interview! Jake Williams, founder of Rendition Infosec and Senior Instructor at the SANS Institute joins us for another interview! In the news, fingerprinting digital documents, Skype finally getting end-to-end encryption, Apple set to patch yet another macOS password security flaw, and more on this episode of Paul's Security Weekly!

Full Show Notes: https://wiki.securityweekly.com/Episode543

Visit https://www.securityweekly.com/psw for all the latest episodes!

Powered by WPeMatico

We Rock This Thing - Enterprise Security Weekly #75

This week, Matt Alderman joins Paul to interview Marci McCarthy, CEO and President of T.E.N. & CEO and Chairman of ISE®! Marci has over 20 years of business management and entrepreneurial experience! In the news, we have updates from Bitglass, WhiteHat, and Twistlock! Matt Alderman talks container security with Paul, and more on this episode of Enterprise Security Weekly!


Full Show Notes: https://wiki.securityweekly.com/ES_Episode75


Visit https://www.securityweekly.com/esw for all the latest episodes!

Powered by WPeMatico

What a start to the year...

It's been a crazy couple days on a couple fronts, but the most material front has certainly been Spectre and Meltdown.

There are lots of sources, and the trick is that while distinctly the root cause lies in the CPU domain and with the CPU manufacturers- the impact touches nearly everything.

It's been keeping the team here busy for a while.

For Dell customers - here's the main place for aggregation of the latest official information and updates - for everything from clients, storage, network, data protection, and CI/HCI.   This page also links to key partner ecosystem official landing pages.

One that I want to call out specifically - VMware customers have some benefits naturally, but updates are still critical, and you can read more on that here.

Yes CI and HCI customers there will be formal system level updates (and they will be on that page) including RCM updates for VxBlock and VxRack FLEX, as well as automated updates for VxRail and VxRack SDDC.   We're aggregating up all the impact assessment and rolling everything into a common update.

For those seeking to understand what this is all about, I would start:

  • Here if you want "just the facts" and are of a comp-sci bent - the Project Zero blog from Google is pretty authoritative on the root cause and how the exploits work (though it was discovered by several groups nearly simultaneously)
  • Here if you want the summary, with some added commentary/snark (in classic El Reg style).

A little bit of personal perspective:

  • IMHO, this falls into the "failure of imagination" error category - like the fire in Apollo 1.   It's so obvious now how speculative execution could be exploited, but it's a facepalm moment.  My 2 cents - witch-hunts don't help, learning does.  We will pick ourselves up, learn, and get better from the failure.
  • I know it's hard - but try to pragmatically work the problem, not guess.  Since the cause is with the CPUs, but the impact is industry wide, lean on your partner ecosystem to help you (certainly not limited to Dell Technologies, there's a lot coming from Intel, ARM, AMD, Microsoft, Google, Apple and others)

To continue the space program metaphor, and to quote the one and only Gene Krantz: "Let's work the problem people. Let's not make things worse by guessing."   

It's only logical that the fixes and workarounds for these 3 exploits will have some degree of performance impact (since they are fixing/working around a flaw in something that is a performance optimization, namely speculative execution).    But - the impact will vary.   I've seen people latch on to early data, or data from one workload or another, or one test that they read online somewhere.   Let's not panic, let's pragmatically work the problem together.

Welcome to 2018!

Powered by WPeMatico