Spectre is the CPU vulnerability that just keeps on giving. Revisions to CVE-2017-5753 and CVE-2018-3693 this week reveal that Spectre 1.1 and 1.2 have emerged from the shadows. So what are they, and how do you mitigate them and any exploits that follow?
Actually, these aren't the first variations on the Spectre theme to emerge; there have been at least four Spectre variants to appear so far.
They are, however, new variants of the original vulnerability and have been dubbed Spectre 1.1 and 1.2 as a result. Like most sequels, they aren't quite as gripping as the original but nonetheless cannot be ignored.
Intel apparently paid US$ 100,000 (£75,591) through the bug bounty program to researchers who uncovered the new speculative execution chip vulnerabilities. You can read the newly published fourth revision of Intel's analysis of speculative execution side channels, which includes the latest information, here:
In a nutshell, Spectre 1.1 can leverage speculative stores to create speculative buffer overflows while Spectre 1.2 enables the targeting of CPUs without the proper read/write protection in order to breach sandboxes. So, do these latest vulnerability disclosures point to an inescapable fact that processor design flaws will continue to be a pain point for security teams for the foreseeable future?
"While so far, threat actors have not been able to capitalize on these vulnerabilities" Lawrence Pingree, Vice President of Product Management at SonicWall points out "the challenge for security professionals is that protection is needed for theoretical future exploits." There's no doubting it's something of a cyber arms-race. "Future exploits built on the Spectre vulnerability could " Pingree warns "allow an attacker to access sensitive information such as passwords, high-value crypto keys, login cookies, VPN credentials and the list goes on."
And let's not forget, as Jonathan Cran who is Head of Research at Kenna Security said in conversation with SC Media UK, that "some affected processors aren't getting more updates, so upgrades will be required to address the issues. The vulnerability/architectural issue affects Nehalem and Westmere (released in 2008 and 2010 respectively) and processors released in 2018. That's 10 years worth of vulnerable systems!"
If systems are allowed to run untrusted code such as VMs or web browsers, for example, then to protect against some of the variants it's "sufficient to apply OS and browser updates" Cran says, adding "but to protect against all, they need to be updated at hardware, OS and application (hypervisor up too)."
Finally, Cran also suggested that enterprise teams need to remember that much application code will need to be recompiled with the /Qspectre switch enabled for example.
"Vulnerability management has to extend to all types of software and hardware throughout the organisation" agrees Luke Potter, Head of Cyber-Security Practice at SureCloud. Historically, vulnerability management teams have mainly focused on operating system level security and patching; wider system coverage has to now be included, such as the firmware on devices, micro-code versions on processors and BIOS versions. "Updates at this level have to form part of an effective cybersecurity strategy" Potter concludes "hopefully CPU design going forward will take these kinds of issues into account."
Assuming that those chip designs are some way off, and the legacy impact will be with us for many years after they do appear, how should the enterprise respond now?
James Plouffe, lead solutions architect at MobileIron is happy to admit that the future is impossible to predict, so the best advice is to have a good handle on the present. "The first two CIS Critical Controls deal with inventory and control of assets and the third deals with continuous vulnerability management" he reminds us, continuing "You can’t protect what you don’t know about and you can’t measure your exposure or the success of your risk mitigation efforts without reliable systems of record and management infrastructure." So focusing on the fundamentals puts the enterprise in the strongest position to effectively deal with more emergent situations by being prepared to respond rapidly.
Gary McGraw, Vice President Security Technology at Synopsys, reckons counting upon chip vendors to issue patches is the best way forward, but adds "by identifying code instances that may be vulnerable to variants of Spectre and Spectre-like attacks, developers can fix their software without relying on hardware or OS-level patches."
We'll leave the final word with the AVP for Security Technology at Aricent, Prakasha M. Ramachandra, who told SC Media UK that enterprise teams should consider Moving Target Defense (MTD) as an option for security architecture, especially for containers. "There are techniques being proposed to scramble machine code and add compiler options to avoid someone accessing cache" Ramachandra says, concluding "pay more focus on static assessment and dynamic analysis of application and firmware source code under development, and adopt continuous, automated penetration tests for digital assets that can be enabled with threat intelligence..."