Windows RT distinguishes itself from Windows 8 in two main ways. First, it runs on ARM processors rather than x86 ones. Second, it bars the installation of third-party desktop applications. The built-in Windows applications like Notepad work, and of course, the bundled Office 2013 apps run on the desktop, but any attempt to run third-party applications is greeted with an error message.

After a little under two-and-a-half months on the market, the first cracks have started to appear in Microsoft's lockdown. A developer going by the name of clrokr has published a way of defeating this limitation, enabling arbitrary desktop applications to be run on Windows RT. The complexities of this crack mean that it stops short of being a useful, practical jailbreak.

Breaking into Windows RT

Windows 8 and Windows RT both use digital signatures to determine whether an application is allowed to run. Windows defines four different "levels" of digital signature: unsigned (for programs with no signature at all), Authenticode (for programs that have a digital signature from any third party), Microsoft (for apps with a Microsoft signature) and Windows (for executables that are part of Windows itself).

The Windows kernel has a function that specifies which signing level a given executable needs. On x86, desktop apps have a required level of "unsigned"—because on x86 the desktop is unrestricted and can run any application. On ARM, however, desktop apps have a required level of "Microsoft." After loading an executable, but before actually running it, Windows compares the executable's signature level to the required level; if the executable's signature is good enough it will run, otherwise Windows just shows an error message and refuses to run the program.

If the function that returned the required signature level could be modified to always indicate that "unsigned" was good enough, then Windows RT would be able to run arbitrary desktop applications. The required signature level is stored within the Windows kernel itself, so the naive solution would be to modify the value in the kernel so that the value was always "unsigned." However, Windows verifies the integrity of its own core components before it loads them. On x86 and x64 Windows, this integrity checking could be bypassed using the same techniques used by malware: there are "bootkits" that load before the operating system and then modify the kernel as it loads to remove the integrity check. With one of these bootkits installed, the modified kernel could be loaded without difficulty.

Secure Boot stands in the way

But this route isn't possible on Windows RT, because of a feature called Secure Boot. Secure Boot is a feature of the UEFI firmware specification that all Windows RT devices are required to support. With Secure Boot, the system's firmware verifies the integrity of the operating system before it loads it. Bootkits fail the Secure Boot integrity check, and the system will fail to boot if a bootkit is in place.

Secure Boot has been a subject of great concern, especially within the Linux community, as the refusal to boot a bootkit also potentially translates into a refusal to boot an alternative operating system. On x86 and x64 machines, vendors are required to provide some way to disable Secure Boot as well as some way to trust alternative operating systems. However, ARM machines don't have this same stipulation. In fact, they do the reverse; Secure Boot is mandatory and permanent on ARM machines, including Surface.

This forced clrokr to find a different way of modifying the kernel. Permanent modification of the file on disk is impossible, but modification of the kernel in memory would allow the signature level to be changed. There are, of course, impediments to doing that. Modifying the kernel is something of a no-no. Fortunately for clrokr, the Windows RT kernel is identical to the Windows 8 kernel—it therefore contains the same security flaws that the Windows 8 kernel suffers from.

One such flaw was documented by Google-employed security researcher Mateusz "j00ru" Jurczyk in November 2011. Certain functions in the Windows kernel are designed to only ever be called by a special Windows process called CSRSS. These functions trust that the data sent by CSRSS is properly formed, so they don't perform proper validation. This can in turn be used to trick the functions into overwriting data in the kernel of an attacker's choosing—data including the required signature level.

If an attacker could persuade CSRSS to call one of these vulnerable functions "just so" he could set the required signature level to "unsigned," thereby allowing any and all desktop applications to run.

Microsoft happened to make this a bit easier for clrokr, because it ships a remote debugger for Windows RT, and because it allows any process to be run as an Administrator. Administrators have the authority to attach debuggers to the special CSRSS process. With a debugger attached, exploit code can be injected into CSRSS, and then one of the vulnerable kernel functions can be called. This overwrites the required signature level, allowing any desktop application to be run. In fact, clrokr's exploit code has to call the vulnerable function 524,288 times to set up the value to be exactly what it should be.

Since its publication on Sunday, people on the XDA Developers forums have been recompiling various applications to run on ARM and running them from the Windows RT desktop. Microsoft's own development tools can be used to produce ARM executables, albeit with a few extra hoops to jump through compared to producing x86 apps, as the ARM development tools are intended only for producing Metro-style applications.

Not yet a jailbreak

More tricky is dealing with people who want the bugs to remain, because they want to be able to run desktop apps on their Windows RT machines.

What does this mean for the Windows RT platform?

In the short-term, not a whole lot.

First, this crack is a long way from a useful jailbreak. The patch needs to be reapplied to the Windows RT system each time it gets rebooted. This in turn means firing up the debugger on the Windows RT device, and connecting a full Windows machine to that debugger over a network to inject the exploit code itself. The attack is also not 100 percent reliable at present; sometimes it can make the machine crash with a blue screen of death.

Second, this means that the crack isn't a serious security flaw. As it stands, the technique can't be used for drive-by browser-based jailbreaks; it requires complex user intervention.

Microsoft's response to the attack makes this very argument:

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 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.

To turn this into a useful general purpose jailbreak requires more work, and more exploitable flaws. The most useful way forward would be to make the jailbreak self-contained, so that it could run entirely on Windows RT. This is tricky, because Windows RT is designed to block the execution of arbitrary code (such as a little program to inject code into CSRSS and perform the exploit). However, applications such as Internet Explorer and Word almost certainly have exploitable arbitrary code execution flaws within them. A suitably crafted webpage or Word document could potentially be used to execute exploit code within these applications.

Normally, user privileges would also be a hurdle; in order to attach to CSRSS, programs need to be running with elevated privileges. For mere jailbreaking, this isn't a huge problem, simply because Windows RT allows any program to be run with elevated privileges. With this we could envisage a jailbreak process along the following lines: start Word or Internet Explorer as an elevated process (clicking through the UAC prompt), then open a locally stored Word document or HTML file that exploits a code execution flaw, attaches to CSRSS, and in turn modifies the kernel.

This would still be complex, due to the anti-exploitation mechanisms that Windows RT inherits from Windows 8, but it should in principle be feasible, as techniques for bypassing these mechanisms are well-known within the hacking community.

To turn it into a serious security flaw, something that could be run by a malicious webpage without user intervention, would require even more exploitation; attackers would have to break out of an unprivileged, sandboxed Internet Explorer before patching the kernel. This has been done before; it will probably be done again. But it's not very easy.

Even this wouldn't represent a permanent jailbreak: rebooting the system would restore it to normal operation, and any patches that repaired any of the flaws being used would prevent future jailbreaking. An effective permanent attack would probably require defeating Secure Boot or Windows' own integrity verification.

Patching problems

If a drive-by jailbreak were developed, Microsoft would certainly be spurred into action. But then the next question is, what can it actually do about it?

Obviously, the company can push out security patches via Windows Update, and anyone who doesn't want to get exploited by drive-by attacks could install the patches.

More tricky is dealing with people who want the bugs to remain, because they want to be able to run desktop apps on their Windows RT machines. Microsoft has no ability to force users to install patches—they can disable the Windows Update service if they really want to—and even if a user has patched their machine, he or she can trivially roll back to an earlier version of the operating system using the system recovery image. It's not clear what provisions, if any, Microsoft has for servicing this recovery image. Currently, doing a full system reset and rebuild from the image removes every security patch applied and reverts the device to the same state that it was in when originally purchased. This gives would-be jailbreakers the permanent ability to undo any fixes that Microsoft might make.

Microsoft's statement strongly implies that the bug being exploited by this crack will be patched in due course, but as it's not considered a security flaw (any "flaw" that requires Administrator rights to exploit isn't really a flaw, after all) there's no particular rush to get it out.

clrokr's stance is that breaking Windows RT's restriction makes it a more useful platform. In the description of the hack, clrokr closes with a request, asking Microsoft to "please consider making code signing optional and thereby increasing the value of your Windows RT devices." The first few apps ported to run on Windows RT's desktop, ssh client PuTTY and remote access tool TightVNC, certainly support this viewpoint; these are apps that lack any good alternative in the Windows Store and which undoubtedly make the platform more useful. Whether Microsoft is willing to entertain such uses, however, is another question. Thus far, the company has shown no willingness to open up Windows RT in this way. With further development of this kind of crack, it soon may not be Microsoft's decision to make.