Apple has already partially implemented fix in macOS for 'KPTI' Intel CPU security flaw
After a public disclosure of a security flaw with nearly every Intel processor produced for the last 15 years, concern grew that a fix may take up to 30 percent of the processing power away from a system. But Apple appears to have at least partially fixed the problem with December's macOS 10.13.2 -- and more fixes appear to be coming in 10.13.3.
Multiple sources within Apple not authorized to speak on behalf of the company have confirmed to AppleInsider that there are routines in 10.13.2 to secure the flaw that could grant applications access to protected kernel memory data. These measures, coupled with existing programming requirements about kernel memory that Apple implemented over a decade appear to have mitigated most, if not all, of the security concerns associated with the flaw publicized on Tuesday.
Further confirming the fixes, developer Alex Ionescu has further identified the code that fixed the issue, and is calling it the "Double Map."
Our sources, as well as Ionescu, say that there are more changes in the macOS High Sierra 10.13.3 -- but both declined comment on what they may be, or what else is required to totally secure users.
AppleInsider is in the midst of comparative speed testing on a 2017 MacBook Pro. Early indications are that there are no notable slowdowns between a system running macOS High Sierra 10.13.1 and 10.13.2.
Mitigations by Linux code-base maintainers are underway, as are changes by Microsoft to protect Windows users. In response to a query, Microsoft told AppleInsider that they had no comment on a timetable of a release to fix the security flaw at this time, but kernel memory handling was altered by the company in Windows 10 beta builds in the end of 2017.
Potentially at risk from the flaw is anything contained in kernel memory, such as passwords, application keys, and file caches. Details surrounding the bug, and how to exploit it, are still under wraps.
Intel is unable to fix the flaw with a firmware update.
Aside from macOS, Microsoft's Windows and Linux are also open to the vulnerability. Beyond personal computers, some believe cloud services like Amazon EC2, Microsoft Azure and Google Compute Engine are impacted by the bug and will need to be updated.
Amazon has alerted its customers to a large security update coming to AWS in February. Microsoft's Azure service has a maintenance period scheduled for Jan. 10.
Multiple sources within Apple not authorized to speak on behalf of the company have confirmed to AppleInsider that there are routines in 10.13.2 to secure the flaw that could grant applications access to protected kernel memory data. These measures, coupled with existing programming requirements about kernel memory that Apple implemented over a decade appear to have mitigated most, if not all, of the security concerns associated with the flaw publicized on Tuesday.
Further confirming the fixes, developer Alex Ionescu has further identified the code that fixed the issue, and is calling it the "Double Map."
The question on everyone's minds: Does MacOS fix the Intel #KPTI Issue? Why yes, yes it does. Say hello to the "Double Map" since 10.13.2 -- and with some surprises in 10.13.3 (under Developer NDA so can't talk/show you). cc @i0n1c @s1guza @patrickwardle pic.twitter.com/S1YJ9tMS63
-- Alex Ionescu (@aionescu)
Our sources, as well as Ionescu, say that there are more changes in the macOS High Sierra 10.13.3 -- but both declined comment on what they may be, or what else is required to totally secure users.
AppleInsider is in the midst of comparative speed testing on a 2017 MacBook Pro. Early indications are that there are no notable slowdowns between a system running macOS High Sierra 10.13.1 and 10.13.2.
Mitigations by Linux code-base maintainers are underway, as are changes by Microsoft to protect Windows users. In response to a query, Microsoft told AppleInsider that they had no comment on a timetable of a release to fix the security flaw at this time, but kernel memory handling was altered by the company in Windows 10 beta builds in the end of 2017.
Potentially at risk from the flaw is anything contained in kernel memory, such as passwords, application keys, and file caches. Details surrounding the bug, and how to exploit it, are still under wraps.
Intel is unable to fix the flaw with a firmware update.
Aside from macOS, Microsoft's Windows and Linux are also open to the vulnerability. Beyond personal computers, some believe cloud services like Amazon EC2, Microsoft Azure and Google Compute Engine are impacted by the bug and will need to be updated.
Amazon has alerted its customers to a large security update coming to AWS in February. Microsoft's Azure service has a maintenance period scheduled for Jan. 10.
Comments
In order to exploit the flaw the "attacker gains physical access by manually updating the platform with a malicious firmware image through flash programmer physically connected to the platform’s flash memory. Flash Descriptor write-protection is a platform setting usually set at the end of manufacturing. Flash Descriptor write-protection protects settings on the Flash from being maliciously or unintentionally changed after manufacturing is completed.
If the equipment manufacturer doesn't enable Intel-recommended Flash Descriptor write protections, an attacker needs Operating kernel access (logical access, Operating System Ring 0). The attacker needs this access to exploit the identified vulnerabilities by applying a malicious firmware image to the platform through a malicious platform driver."
as explained by Intel:
https://www.intel.com/content/www/us/en/support/articles/000025619/software.html
In everyday's language, the attacker needs physical access to your computer's interior. And all the efforts for what? For accessing kernel VM pages into which macOS never puts critical information. Holding critical information in wired memory is the ABC of kernel programming in Apple programing culture. That wired memory is the one that cannot be paged to VM. When the computer is turned off no critical information resides anywhere in your storage media.
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
This issue is about user-level software being able to access kernel-level data. As Intel says, there are other attacks that do similar things:
https://www.vusec.net/projects/anc/
http://www.tomshardware.com/news/aslr-apocalypse-anc-attack-cpus,33665.html
http://www.cs.ucr.edu/~nael/pubs/micro16.pdf
These try to bypass a security feature (ASLR), rather than being a direct security flaw:
https://security.stackexchange.com/questions/18556/how-do-aslr-and-dep-work
One way they do it according to the Kaiser paper is to measure the timings between a memory access and error handler callback. When it hits the cache the timings change so they can figure out where the legitimate memory addresses are:
https://gruss.cc/files/kaiser.pdf
That paper suggests ARM isn't affected as it uses separate mapping method for user and kernel tables:
"All three attacks have in common that they exploit that the kernel address space is mapped in user space as well, and that accesses are only prevented through the permission bits in the address translation tables. Thus, they use the same entries in the paging structure caches. On ARM architectures, the user and kernel addresses are already distinguished based on registers, and thus no cache access and no timing difference occurs. Gruss et al. and Jang et al. proposed to unmap the entire kernel space to emulate the same behavior as on the ARM architecture."
According to Intel, it doesn't allow write access. Maybe it's possible to get read access to sensitive data, this seems to be the case given the system updates. They are trying to come up with an industry-wide solution. Maybe there's a way to obfuscate memory data using a random key like a bit-shift operation and hide the key. It might be too slow for some things but worthwhile for sensitive data like passwords and encryption keys, which don't need to be accessed frequently. OS developers can do this themselves.
EDIT: Nope. Mine has the incompatible Broadcom WiFi chip. Oh well...
Apparently I posted a wrong technical note.
AI must do a lot of more editing than me to correct all references to "silicon-level flaw" and alike right now