Windows RT: Bug not a bug?

Microsoft, kernel expert take sides on whether this week's Windows RT flaw is a security vulnerability that needs to be patched

Microsoft and a respected researcher disagreed this week about whether a bug in Windows RT is actually a security vulnerability that should be patched.

The bug, revealed Jan. 5 by a hacker known as "clrokr," can be used to bypass a restriction in Windows RT that prevents its "desktop" mode from running anything but select, Microsoft-made software. By changing a byte in the Windows RT kernel, said clrokr, Windows RT users could install standard Windows applications -- assuming they had been recompiled for the OS's ARM processor -- and run them on the desktop.

[ Windows 8 is here, and InfoWorld covers Microsoft's new direction, the touch interface for tablet and desktop apps, the transition from Windows 7, and more in the Windows 8 Deep Dive PDF special report. | Stay atop key Microsoft technologies in our Technology: Microsoft newsletter. ]

By default, only Microsoft's Office RT, a scaled-down version of Office 2013; IE10 (Internet Explorer 10); the File Explorer file manager; and several other utilities created by the Redmond, Wash. developer, are allowed on the Windows RT desktop.

Other hackers have taken clrokr's work to actually install recompiled Windows apps on RT-powered devices.

Most have portrayed clrokr's discovery as a "jailbreak," meaning a way for do-it-yourselfers to sneak unauthorized software onto a tablet running Windows RT. Jailbreaks have been used for years by iPhone owners to install apps that have not been approved by Apple for its App Store distribution market.

But the same technique could also be used to install malicious software, argued Tarjei Mandt, a researcher who has found dozens of security vulnerabilities in the Windows kernel, and reported them to Microsoft for patching. Mandt works as a senior security researcher for Azimuth Security, an Australian security consultancy founded by researchers formerly at IBM's Internet Security Systems XForce.

"This is not your traditional security vulnerability, as it already requires the user to have administrative privileges, [which is] the reason why Microsoft doesn't classify it as a security vulnerability," Mandt said in an email interview. "[But] if the goal of the operating system is to prevent unverified drivers and executables from running, as the case is with Window RT, then in my opinion it should be classified as a security issue or security bypass."

Microsoft doesn't see it that way.

"The scenario outlined is not a security vulnerability and does not pose a threat to Windows RT users," Microsoft categorically said Tuesday in a statement. The company also hinted at its rationale: "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," Microsoft said.

True, acknowledged Mandt, who admitted clrokr's tactic had flaws. "Although the attack in this case can be used to disable [Windows RT's] signature enforcement at runtime, launching something that can survive a reboot is a completely different story due to the extensive verification made by UEFI Secure Boot," Mandt said.

UEFI Secure Boot is a security measure supported by Windows RT -- and its parent, Windows 8 -- that blocks unsigned code from running at boot time, essentially quashing malware attempting to inject itself into the boot process.

Because of Secure Boot, clrokr's bypass can't survive a reboot, meaning that the kernel bug would have to be re-triggered, and the unauthorized app re-installed, each time the device is turned on.

"If it didn't require this step, then the threat would be much more severe, as it could easily be bundled as a payload in a browser exploit or [something] similar," said Mandt. "In order to survive a reboot, additional steps would need to be taken such as leveraging additional vulnerabilities."

Although those hypothetical vulnerabilities have yet to be found, Mandt was concerned enough about the possibility to urge Microsoft to fix the bug and harden Windows RT.

"Once the executable is running, there are no mechanisms that prevent the attacker from modifying the code in memory," Mandt observed. "If Microsoft adopted a code-signing scheme similar to that of iOS, as well as addressed obvious kernel information disclosure techniques such as the one used by clrokr, then exploitation of these vulnerabilities would be notably harder."

Without such changes, Mandt believed that Windows RT, like iOS, would eventually be jailbroken, leaving it open to attack by malicious code posing as a desktop application. "It seems likely that Windows RT will be permanently jailbroken at some point," he said. "Windows RT tries to be a hybrid tablet and desktop OS, unlike Apple's iOS which is a very stripped-down version of OS X. This offers a lot more attack surface and, in theory, should make it easier for an attacker to jailbreak the device."

Microsoft left the change door open, telling other news outlets earlier in the week, "We'll not guarantee these approaches will be there in future releases."

In related news, on Thursday a developer going by "Netham45" released a batch file that automated the jailbreak technique demonstrated by clrokr, giving non-technical owners of Windows RT devices, such as Microsoft's Surface RT tablet, an easy way to exploit the kernel vulnerability.

Gregg Keizer covers Microsoft, security issues, Apple, Web browsers and general technology breaking news for Computerworld. Follow Gregg on Twitter at @gkeizer, on Google+, or subscribe to Gregg's RSS feed. His e-mail address is See more articles by Gregg Keizer.

Read more about tablets in Computerworld's Tablets Topic Center.

This story, "Windows RT: Bug not a bug?" was originally published by Computerworld.

Copyright © 2013 IDG Communications, Inc.