Windows RT: Fortified against malware

Even Microsoft’s lawyers say it: Windows RT isn’t Windows. In fact, Microsoft is releasing two different operating systems: Windows 8 and Windows RT (Run Time). While the two versions look alike on the Metro layer, Windows RT stands apart for two reasons: It runs only on ARM-based systems such as Microsoft Surface, and the traditional Windows desktop is gone, which means the only non-Metro applications that work with Windows RT come with the OS.

The differences between Windows 8 and Windows RT carry over to computer security. Some Windows RT characteristics decrease security risk, but there are missing features as well.

Windows RT apps: More secure by default With Windows RT, all nondefault apps must be downloaded from the Windows Store (similar to Apple’s App Store). This has huge security implications. Windows Store applications are all Metro-style applications. They all use the Windows RT API and contain significant security improvements by default.

Windows RT apps can only be written in programming languages that contain today’s expected default security settings; buggier, older programming languages need not apply. This also means that Windows RT apps contain all the Windows anti-buffer-overflow memory improvements introduced in Windows Vista and improved in each Windows version since. These include Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), SafeSEH, sacrificial canary values, and more. What is different is these memory protections are improved — and required.

In previous versions of Windows, you could define exceptions. Not so with Metro-style apps — the only types of applications allowed to run on Windows RT. Want to run a legacy app? You’re out of luck with Windows RT.

In the same vein, in Windows 8, Windows Store applications will run only if you leave User Account Control (UAC) enabled. It’s all or nothing. UAC is probably the single best feature Windows users can run to protect themselves against silently installed malware, so it makes sense to force those who wish to run Windows Store apps to keep UAC on.

Windows Store apps are also tested and certified by Microsoft to be free of thousands of common fatal bugs and security problems. As a result, millions of malicious programs that target traditional Windows desktops simply won’t be able to convince end-users into running them.

In the event that a Windows store app ends up being malicious (which has occurred in Apple’s App Store in the past), Microsoft can revoke the application. Which brings us to another restriction: All Windows Store applications are digitally signed, and Windows RT will refuse to load modules not signed by Microsoft. This is a huge protection.

Containment policies Nonetheless, criminals are certain to try and install their malware on Windows RT devices with client-side buffer overflows, zero days, and other types of desktop exploits. But even if they succeed in doing so, because the malware won’t be signed and won’t originate from the AppContainer, Windows RT won’t load it. Will the bad guys get around these protections? Perhaps, but it makes their mischief significantly harder to pull off.

The AppContainer, which all Windows RT applications will run in by default, has sandbox security features. While I’m not a huge fan of security sandboxes over the long term, there’s no denying they make the attacker’s job more difficult in certain circumstances. In Windows RT, Windows Store applications will have a hard time reading and writing outside of the AppContainer, creating new network connections, or accepting new inbound connections. If the Windows Store app needs that sort of access, it will be declared and transparent to the user.

Note, however, that this sort of declarative need for features outside the security sandbox has been a default feature in other languages, such as Java, for more than a decade. It hasn’t, by itself, resulted in better security.

Where the security sandbox features of the AppContainer will be especially useful is in blocking the sharing of browser cookies and files with other applications. This new boundary will block a ton of malicious apps that prey upon cookie stealing or using out-of-boundary attacks to launch files previously stored as temporary Internet files and the like.

More lines of defense Better, the Metro version of Internet Explorer 10 — the only version allowed on Windows RT — will not load add-ons. Considering that the majority of today’s successful attacks launch from third-party add-ons, this is a huge security improvement.

Suppose the bad guy gets around all the previous protections we’ve discussed. They still have one huge hurdle to overcome: Windows RT runs on ARM processors. Ninety-nine percent of today’s malware runs for x86 processors and will not run on ARM processors. That means hundreds of millions of malicious programs that exist today will not work on Windows RT. That’s huge!

Yes, you can expect malware writers to become ARM-educated and to produce malware capable of doing bad things on Windows RT. But Windows RT immediately means over two decades of malware education and skills are no longer relevant.

What’s missing in RT Windows RT will offer significantly lower security risk than its Windows 8 counterpart, thanks primarily to a new processor model and fewer attack vectors. But what will Windows RT users have to give up?

The biggest and most notable missing feature is the inability to join Windows RT devices to an Active Directory domain. This will be a showstopper in numerous environments because Windows RT users will not be subject to the group policies many enterprises rely upon. Eventually, you can expect MDM vendors to offer some sort of management control. Microsoft itself has announced coming improvements in Microsoft SCCM and Windows Intune that will be directed toward Windows RT devices.

Another missing feature is BitLocker Drive Encryption. Windows RT devices will support their own full-disk encryption enabled by default. It goes without saying that Microsoft will not support Encrypting File System (EFS) in Windows RT, but with full-disk encryption, you don’t need it.

The bottom line is that the inherent security of Windows RT devices — in terms of vulnerability to attack — is pretty much ironclad. But the lack of support for Active Directory will limit the use of Windows RT devices in the enterprise.

This article, “Windows RT: Fortified against malware,” was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest business technology news, follow InfoWorld.com on Twitter.