Security Researchers Find Hardware-Level Security Flaw in Intel Processors
A new security post at the Xen.org community blog warns Intel users to patch their operating systems or risk falling prey to a particular type of escalation vulnerability. What makes this warning unique is that it's not related to a software problem only effects Intel users running 64-bit operating systems. This is an issue that affects Windows (Microsoft has released a patch) and may affect netBSD, FreeBSD, and OSX as well.
The overwhelming majority of end users have never had to worry about the difference between AMD's implementation of its x86-64 standard and Intel's later copy, but there are subtle differences between the two. In this particular case, one of those differences turns out to be a problem. When operating in 64-bit mode, both Intel and AMD chips check to ensure that virtual addresses above bit 47 are written canonically. If they aren't, the CPU throws a general protection fault. How the fault is thrown and what happens after is slightly different between the two architectures, thus creating the security flaw.
The US-CERT disclosure states that "A local authenticated attacker may exploit this vulnerability for operating system privilege escalation or for a guest-to-host virtual machine escape."
Intel, predictably, claims that this is a feature not a bug. The company's vendor disclosure page states, "This is a software implementation issue. Intel processors are functioning as per specifications and this behavior is correctly documented in the IntelR64 Software Developers Manual, Volume 2B Pages 4-598-599."
The danger from the problem is fairly slim; users would need local login credentials and system access. There's some risk that software running in a virtual machine could use this exploit to break out of the sandbox (so to speak), but a remote hacker couldn't leverage the problem to take over a system.
Given that AMD chips aren't affected and AMD wrote the x86-64 standard that Intel later copied, we're a bit dubious of the company's attempt to push this off as a software problem. The subtle difference alluded to above is precisely that certain hardware functions are performed differently on Intel CPUs than on AMD chips. As the Xen.org blog states:
"Because Intel’s implementation of SYSRET matches their published spec, they consider their processors to be behaving correctly. However, the SYSRET instruction was defined by AMD as part of the x86-64 architecture, and Intel’s version is obviously intended to be compatible with AMD’s version. If the majority of operating systems (acting independently) managed to “not properly handle uncanonical return addresses on Intel EM64T CPUs”, it’s hard not to conclude that Intel made a mistake when designing their specification."
Microsoft's patches and advisory are located here. Full US-CERT and vendor-specific information can be found here.
The overwhelming majority of end users have never had to worry about the difference between AMD's implementation of its x86-64 standard and Intel's later copy, but there are subtle differences between the two. In this particular case, one of those differences turns out to be a problem. When operating in 64-bit mode, both Intel and AMD chips check to ensure that virtual addresses above bit 47 are written canonically. If they aren't, the CPU throws a general protection fault. How the fault is thrown and what happens after is slightly different between the two architectures, thus creating the security flaw.
The US-CERT disclosure states that "A local authenticated attacker may exploit this vulnerability for operating system privilege escalation or for a guest-to-host virtual machine escape."
Intel, predictably, claims that this is a feature not a bug. The company's vendor disclosure page states, "This is a software implementation issue. Intel processors are functioning as per specifications and this behavior is correctly documented in the IntelR64 Software Developers Manual, Volume 2B Pages 4-598-599."
The danger from the problem is fairly slim; users would need local login credentials and system access. There's some risk that software running in a virtual machine could use this exploit to break out of the sandbox (so to speak), but a remote hacker couldn't leverage the problem to take over a system.
Given that AMD chips aren't affected and AMD wrote the x86-64 standard that Intel later copied, we're a bit dubious of the company's attempt to push this off as a software problem. The subtle difference alluded to above is precisely that certain hardware functions are performed differently on Intel CPUs than on AMD chips. As the Xen.org blog states:
"Because Intel’s implementation of SYSRET matches their published spec, they consider their processors to be behaving correctly. However, the SYSRET instruction was defined by AMD as part of the x86-64 architecture, and Intel’s version is obviously intended to be compatible with AMD’s version. If the majority of operating systems (acting independently) managed to “not properly handle uncanonical return addresses on Intel EM64T CPUs”, it’s hard not to conclude that Intel made a mistake when designing their specification."
Microsoft's patches and advisory are located here. Full US-CERT and vendor-specific information can be found here.
