“The scenario outlined is not a security vulnerability and does not pose a threat to Windows RT users,” Microsoft said in its statement. “The mechanism described is not something the average user could, or reasonably would, leverage, as it requires local access to a system, local administration rights and a debugger in order to work.”
“We applaud the ingenuity of the folks who worked this out and the hard work they did to document it,” the company further said, but added that the hole at the heart of this hack may not remain unplugged for too long.
According to C.L. Rokr, the hack was made possible thanks to a Windows kernel vulnerability that has been around for a while. Although the said bug makes it possible to alter the “minimum signing level” in a way that it becomes possible to execute unsigned code on Windows RT, any change effected in this manner is undone as soon the system reboots.
“The minimum signing level determines how good an executable’s signature is on a scale like this: Unsigned(0), Authenticode(4), Microsoft(8), Windows(12),” clrockr wrote in a blog post detailing the hack. “The default value on x86 machines is of course 0 because you can run anything you like on your computer. On ARM machines, it defaults to 8.”
“This is not a user setting, but a hardcoded global value in the kernel itself. It cannot be changed permanently on devices with UEFI’s Secure Boot enabled. It can, however, be changed in memory,” the security researcher added.
“Finding this byte in the kernel takes a while, there is no exported symbol for it and not even in the symbol database at MSFT. I found it using WinDbg and a machine running Windows 8 Pro, creating processes and watching how the system behaves when the signature checks happen all the way through CI.dll and back.”
C.L. Rockr believes that this hack underscores the fact that Windows RT is a “clean port” of Windows 8 and that any incompatibility between the two is superficial.