First details emerge about new batch of Intel processor security flaws [u]
Details of the first of the second wave of Spectre-style vulnerabilities in Intel processors has been published earlier than expected, with the "LazyFP" vulnerability potentially allowing an attacker to access sensitive data, such as cryptographic keys.
Part of a secondary collection of processor vulnerabilities discovered following the Spectre and Meltdown disclosures, LazyFP (CVE-2018-3665) was originally found by researchers working for Amazon and Cyberus Technology earlier this year. As part of the process of responsible disclosure, details of the flaw were provided to Intel and other related firms, with a release to the public scheduled after a defined period of time had taken place.
In May, it was reported Intel had successfully negotiated with researchers to delay the release by a few weeks, but wanted to push it further back, potentially until July. According to Cyberus, the embargo was set to lift in August, but rumors of the vulnerability forced an earlier disclosure, possibly to try and pressure Intel and other vendors to work faster in creating and implementing a solution.
While the LazyFP whitepaper explaining the issue is being withheld, following a request by Intel, some details about how the vulnerability works have been issued.
LazyFP centers around the use and abuse of the Floating Point Unit (FPU), and associated registers in the processor. To enable multitasking, the FPU needs to be able to store its state in order to switch between tasks.
Using what is described by Intel as a "Lazy FP state restore technique," the restoration of an FPU's state can be delayed until an instruction operating on it is executed by a new process. "Eager FPU switching" saves the state on a context switch without any delay, whereas the "lazy" version is an optimized way that accounts for processes that don't use the FPU all the time.
While the details of the attack are not explained, it is suggested it is based on the manipulation of the FPU and how it holds data while the Lazy FP technique is used.
According to Intel's advisory report on the vulnerability, it has a severity rating of "moderate," and is described as affecting "Intel Core-based microprocessors," but not specific models. There is also no mention of which operating systems are affected by the vulnerability.
In a statement to AppleInsider, Intel said the "Lazy FP state restore" is similar to Variant 3a and has already been addressed for "many years" in client and data center products.
"Our industry partners are working on software updates to address this issue for the remaining impacted environments and we expect these updates to be available in the coming weeks," Intel said. "We continue to believe in coordinated disclosure and we are thankful to Julian Stecklina from Amazon Germany, Thomas Prescher from Cyberus Technology GmbH, Zdenek Sojka from SYSGO AG, and Colin Percival for reporting this issue to us. We strongly encourage others in the industry to adhere to coordinated disclosure as well."
It is unknown if Apple has been affected by the flaw, but as all current Macs and MacBooks use Intel processors and have done for a number of years, it is still plausible. Apple usually posts details about the vulnerabilities it fixes in its software on its security updates page, but there doesn't appear to be a reference to the latest disclosure as of yet.
Revealed in January, the Meltdown and Spectre chip flaws in Intel and ARM-based processors allowed the creation of a number of exploits in systems using the components. All Mac and iOS devices were found to be affected by the issue, but Apple advised at the time it had already mitigated the issues for current operating system versions, and was working to develop other fixes.
The more recent batch of eight similar security flaws were found to be caused by the same design-related issue, and includes four classified by Intel as "high risk." While seven of the eight are thought to have the same impact as Spectre, the eighth is thought to be a greater threat against enterprise systems, in being able to allow attackers to exploit a virtual machine to attack the host.
Updated with statement from Intel.
Part of a secondary collection of processor vulnerabilities discovered following the Spectre and Meltdown disclosures, LazyFP (CVE-2018-3665) was originally found by researchers working for Amazon and Cyberus Technology earlier this year. As part of the process of responsible disclosure, details of the flaw were provided to Intel and other related firms, with a release to the public scheduled after a defined period of time had taken place.
In May, it was reported Intel had successfully negotiated with researchers to delay the release by a few weeks, but wanted to push it further back, potentially until July. According to Cyberus, the embargo was set to lift in August, but rumors of the vulnerability forced an earlier disclosure, possibly to try and pressure Intel and other vendors to work faster in creating and implementing a solution.
While the LazyFP whitepaper explaining the issue is being withheld, following a request by Intel, some details about how the vulnerability works have been issued.
LazyFP centers around the use and abuse of the Floating Point Unit (FPU), and associated registers in the processor. To enable multitasking, the FPU needs to be able to store its state in order to switch between tasks.
Using what is described by Intel as a "Lazy FP state restore technique," the restoration of an FPU's state can be delayed until an instruction operating on it is executed by a new process. "Eager FPU switching" saves the state on a context switch without any delay, whereas the "lazy" version is an optimized way that accounts for processes that don't use the FPU all the time.
While the details of the attack are not explained, it is suggested it is based on the manipulation of the FPU and how it holds data while the Lazy FP technique is used.
According to Intel's advisory report on the vulnerability, it has a severity rating of "moderate," and is described as affecting "Intel Core-based microprocessors," but not specific models. There is also no mention of which operating systems are affected by the vulnerability.
In a statement to AppleInsider, Intel said the "Lazy FP state restore" is similar to Variant 3a and has already been addressed for "many years" in client and data center products.
"Our industry partners are working on software updates to address this issue for the remaining impacted environments and we expect these updates to be available in the coming weeks," Intel said. "We continue to believe in coordinated disclosure and we are thankful to Julian Stecklina from Amazon Germany, Thomas Prescher from Cyberus Technology GmbH, Zdenek Sojka from SYSGO AG, and Colin Percival for reporting this issue to us. We strongly encourage others in the industry to adhere to coordinated disclosure as well."
It is unknown if Apple has been affected by the flaw, but as all current Macs and MacBooks use Intel processors and have done for a number of years, it is still plausible. Apple usually posts details about the vulnerabilities it fixes in its software on its security updates page, but there doesn't appear to be a reference to the latest disclosure as of yet.
Revealed in January, the Meltdown and Spectre chip flaws in Intel and ARM-based processors allowed the creation of a number of exploits in systems using the components. All Mac and iOS devices were found to be affected by the issue, but Apple advised at the time it had already mitigated the issues for current operating system versions, and was working to develop other fixes.
The more recent batch of eight similar security flaws were found to be caused by the same design-related issue, and includes four classified by Intel as "high risk." While seven of the eight are thought to have the same impact as Spectre, the eighth is thought to be a greater threat against enterprise systems, in being able to allow attackers to exploit a virtual machine to attack the host.
Updated with statement from Intel.
Comments
Hopefully modern browsers will eventually be able to detect a compromised site before the code actually loads in your browser and stop executing the the web page with a warning.
I choose not to worry about this stuff as a consumer level user. This current crop of CPU vulnerabilities have been known since January. Where are the commercial data breaches because of them? Who has been hacked by them? The security research community has always been prone to cry wolf and exaggerate the actual threat. I can remember several apocalyptic predictions from the security pundits that never made it to the real world, from SSL, to WPA2, to Spectre and Meltdown, to Russians invading my router. Should these things be ignored? No. Should they be dealt with and fixed? Yes. But when I hear a security pundit or some anonymous comment advising me that the world as I know it will end in a blaze of data theft and we are all doomed it really just puts a smirk on my face.
A CoBOL programmer I used to know (passed away unfortunately) came out of retirement for one day on 31st December 1999. His old company paid him £30,000 to be on hand for ‘fixes’ on the last day of the century.
Nothing happened, because like every other programmer I’ve ever met, he knew the century would end eventually when he wrote the stuff.
The "design for" aspect is at the heart of nearly all of the security flaws that exist in products today. The Intel chips and algorithms in question were not subjected to rigorous "design for security" imperatives at the time they were built. This wasn't an oversight but rather simply not a design imperative at the time like design for performance, design for energy efficiency, design for reliability, etc., and many other design goals at the time. Fortunately, products that also included design for modifiability objectives are usually better off and sometimes able to compensate for emerging requirements, but as we have seen some changes are not possible and the compensation needs to occur at other levels in the system, like the operating system or even relegated to external compensation like firewalls and proxies.
We should avoid rewriting history. Y2K was a systematic set of shortcomings in systems that had survived much longer than their designers anticipated and hence had no idea that year numbers might not begin with '19' and many related issues* The industry recognised and addressed the issue in a large process of verifying and correcting systems. It did this so well that people now say 'what was all the fuss'; things would have been different if it hadn't been successful.
My personal contribution to this was in the mid-80s when we were programming an embedded system with a design life of 25+ years. The clock/calendar software was bespoke and I remember sending one of the programmers off to the library (no web in those days) to check whether or not 2000 was a leap year. Come the late-90s, all that kit had to be audited; someone came back to me to tell me that this piece of kit was clean - I think I smirked when I said "I know".
*In the UK, cheque books used to come with a pre-printed '19' ready to enter the year of writing the cheque. They had to be changed too.