Levi, Ray & Shoup, Inc.

Meltdown and Spectre

1/5/2018 by Greg Hetrick

By now almost everyone has heard about the critical flaws found in modern CPU architecture that impacts Intel, AMD and ARM based CPUs. What was just made public was a pair of side channel attacks against a method known as speculative execution.  One attack named Meltdown (Intel Only) is able to read kernel memory, and the other, named Spectre, is able to read memory from within the given process. For Meltdown, this means you can force a computer to reveal memory outside of the application that is running. For example, a piece of malicious software reading memory and pulling out passwords from a user’s password management tool. This could go even further and result in a remote attack via a vulnerable browser. Firefox and Chrome have both pushed patches that would fix browser problems, regardless of the state of the operating system patch. One of the biggest concerns is the potential of reading memory from other virtual machines in a cloud environment. In theory it is possible to have VM on a shared piece of hardware and be able to read memory contents from the host, which would include memory from other VMs on that host. All major cloud providers have issued patch notices that will require reboots.

If you want to learn more about the flaws mentioned above, a good place to start is with this ArsTechnica article: (https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-every-modern-processor-has-unfixable-security-flaws/).


Meltdown long term impact seems to be privilege escalation via access to sensitive memory information (passwords, encryption keys, session tokens, etc..) and container/paravirtulization hypervisor escape.

Spectre seems to be most damaging in memory around a browser, such as stealing session tokens from sensitive websites. For example: user is logged in to bank account on one tab and gets hit by a malicious JavaScript drive by ad on another tab.  Theoretically the JavaScript could steal the valid session token from browser memory. This would even bypass multi-factor authentication. The other option is more in depth by leveraging Spectre as a method to bypass ASLR (Address Space Layout Randomization).  This is a memory protection scheme designed to make software exploitation much harder or impossible. If we can leak memory location it could lead to a whole new method for browser exploitation.

What does this mean for LRS customers?

RedHat reports this impacts Linux on IBM System Z, Power 8, Power 9 as well as Intel and AMD processors. At the time of this post IBM has not announced the impact to Z/OS. IBM Power 7+ and newer systems should expect a firmware update on 1/9. Generations prior to 7+ will be reviewed and announcements forthcoming. Operating system patches for AIX and system I will be available 2/12.

To follow for updates from IBM watch the IBM PSIRT Blog: (https://www.ibm.com/blogs/psirt/).

For more information from RedHat’s, read their post here: (https://access.redhat.com/security/vulnerabilities/speculativeexecution).

This doesn’t impact just RedHat Linux. All versions of Linux, Windows, MacOS are impacted as well. As of the time of this post, Windows and Linux have released patches for Meltdown. MacOS patch was released in early December for Meltdown and they have promised patches to address Spectre soon.

As of this post, Amazon’s AWS and Microsoft’s Azure environments have been fully patched.

This is likely going to be a challenge for a considerable period of time because it exits in hardware. The CERT notification currently lists the solution as “Replace CPU Hardware.” This is a tall order. CPUs will take years to age out and be replaced. Many systems can’t be updated or replaced so will never be corrected for this flaw.

Technology teams need to patch to address these issues, but this is not without some testing. Any application that has deep ties in the kernel can have issues, reports of Anti-Virus products causing issues (including Symantec causing as BSOD) have been reported. Kevin Beaumont (@GossiTheDog) has a running list of A/V vendors and their compatibility with the windows patch. https://docs.google.com/spreadsheets/d/184wcDt9I9TUNFFbsAVLpzAtckQxYiuirADzf3cL42FQ/htmlview?usp=sharing&sle=true

Because speculative execution is a performance enhancement and the patches have to mitigate the performance improvements that are gained. Patching will cause performance degradation. In most cases this will be less than a 5% impact, however in systems that make significant number of syscalls users are being warned that the impact could be as much as 30%.

LRS Recommendations

My recommendation is to continue to follow a risk-based patching program. Patches exist for Mozilla and Google Chrome that will mitigate Spectre JavaScript based attacks. I would start with all user workstations and those browsers. Typical workload on a workstation will not be performance impacted so patches can be implemented once testing has been completed.

As teams move towards datacenters they will need to look at the associated risk an make an educated decision on whether or not to patch.  In some cases, the risk may outweigh the reward.  For example, is there a large multi-tenant environment with both sensitive data and untrusted users?  Since this has the potential for hypervisor escape, this might be a higher risk environment than a single tenant server with no or limited external access.

I encourage you to read release notes for all patches.  Microsoft has chosen to not enable the mitigation after the patch is applied in server installations to allow teams time to assess performance impact.  Once the patch is installed and the system rebooted, 2 registry keys will need to be modified to enable the mitigation. For more information see here: https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution

As someone pointed out, this is bad, but the sky isn’t falling.

Rest assured that the LRS Security team is monitoring this closely and will continue to update our blog as more information is released.  Our team of experts is here and ready to help if you have concerns or questions. 

Flaw in action

CVEs Assigned

CVE-2017-5753, CVE-2017-5715, and CVE-2017-5754

Additional Information




Greg Hetrick is our Security Solutions Technical Advisor and Penetration Testing Lead, and he focuses on helping customers identify gaps and achieve security goals. Prior to joining LRS Greg held roles as a red and blue team leader in a large financial services company and a large academic medical research hospital. He holds multiple certifications in the area of Information Security including: OSCP, GWAPT, GISP, GPEN, GXPN, and CISSP.