An independent developer has discovered a way to run unsigned desktop applications on Microsoft's Surface running Windows RT. The exploit takes advantage of a kernel bug that exists in Windows 8 and was consequently inherited by WinRT. C.L. Rokr discovered the vulnerability that allows “unsigned desktop applications to be run on Windows RT”. Similar InfoQ spoke with Rokr to discuss the research.
InfoQ: What is your computing background?
Rokr:
I'm a professional embedded application developer. I have always found reverse engineering fascinating, but I never found a good job that had RE aspects.
InfoQ: How long did it take you to research and develop the exploit?
Rokr:
I had known that the vulnerability existed for quite some time, but its usefulness was very limited. So it could subtract 1 of the value at any given address in a data segment. There is no way to actually change the code because those pages are read only. Finding a suitable spot in the kernel took about three weeks, mainly because I'd never looked so closely at Windows before.
InfoQ: What was your motivation for doing the project? To unlock your device to run the applications that you wanted or just curiosity?
Rokr:
The moment I found out my new Visual Studio had an ARM target, I compiled a sample Win32 app. Then I waited for my Surface to arrive. During an AMA session at Reddit, the Surface team clearly said legacy apps would not run on Windows RT, but I was convinced they just meant that x86 code would not run on ARM machines which was pretty clear to me. Later someone mentioned code signing, and I was once again sure that this was just a part of the local security policy and could be disabled by the user because that is what Microsoft does. You can imagine my face when I tried out the sample on the Surface for the first time and it wouldn't run. It just had to.
InfoQ: You wrote, "Ironically, a vulnerability in the Windows kernel that has existed for some time and got ported to ARM just like the rest of Windows made this possible."
Rokr:
It's strange. Microsoft really wanted Windows 8 and Windows RT to be different, but in the end their similarity was the reason I could pull this off at all. Static analysis helps of course, but having a live system with kernel debugging enabled made it possible to pinpoint everything important in a shorter amount of time without having to wire up my Surface to a logic analyzer (and I'm not sure this is possible, some people say the Tegra3 is a stacked package with RAM on top)
InfoQ: With that in mind, how hard is it to conduct the exploit on Windows 8?
Rokr:
If Windows 8 had shipped with the same restrictions, the procedure would work just the same. I initially developed this procedure on Windows 8 because I could use the kernel debugger to restrict it just like Microsoft did with RT and then find my way out.
InfoQ: Others seem to consider this a non-issue, but how easily could Microsoft correct this? Simply release a "must-have" system update?
Rokr:
Microsoft will fix this like any other vulnerability, and that is a good thing. Still, if they don't make Code Integrity optional, I will find another one. And if I don't, someone else will.
Multiple news sites have reported the following response from Microsoft to Rokr's work:
Microsoft:
The scenario outlined is not a security vulnerability and does not pose a threat to Windows RT users. 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. In addition, the Windows Store is the only supported method for customers to install applications for Windows RT. There are mechanisms in place to scan for security threats and help ensure that apps from the Store are legitimate and can be acquired and used with confidence.
We applaud the ingenuity of the folks who worked this out and the hard work they did to document it. We'll not guarantee these approaches will be there in future releases.