1,777 views
HITB2012AMS Day 1 – WinRT The Metro-politan Museum of Security
WinRT : The Metro-politan Museum of Security
Sébastien Renaud and Kévin Szkudlpaski start their talk by introducing themselves. They both work as Security Researcher at Quarkslab, focusing on reverse engineering, dissecting network protocols and file formats. They will talk about the Windows Runtime, the foundation for the Metro platform in Windows 8.
The agenda for this talk contains the following items.
- Windows 8
- WinRT – Applications & Components
- WinRT – Internals
- Windows Store
- Sandbox
- Conclusions
Windows 8
Sébastien explains that their research started out of curiosity for the new Windows 8 operating system. They wanted to look at the Windows 8 and diff the Windows 7 RTM kernel versus the Windows 8 DP (Developer Preview) Kernel. During the research, they discovered an interesting new API.
Windows 8 has a new UI, called Metro. The start button has disappeared in the Windows 8 Desktop. WinRT is the backbone of Metro apps and introduces a new programming model.
Metro apps, Sébastien continues, are only distributed through the Windows Store. They are executed in an “App Container”, which means:
- secured through a sandbox
- severely limited resources access, and explicit permissions needed
- Uses a restricted subset of .Net and Win32 API’s.
WinRT – Applications & Components
Windows 8 provides a layered approach to develop and run applications. There’s a variety of development environments and languages you can use for Metro applications.
Applications get installed per user. You don’t need to have administrative privileges to install/run those applications. They are packaged (*.appx) for deployment. The package is signed, compressed, contains ALL needed files and can target multiple platforms (x86, x64, ARM).
To install an application, you’ll need to visit the Windows Store. Inside the package, there’s an AppxManifest.xml file, which describes the application registration, including Application, Capablities and Extensions definitions. The manifest contents get mapped into registry keys, stored under HKCU. The application itself gets stored somewhere under the Windows.Launch extension.
Capabilities define what the app can do or what it needs to access:
- Network: Enterprise auth, client, server & client, Intranet, Text Messaging, etc
- File System: Document, Pictures, Music, Video
- Devices: Location (GPS), Mic, Proximity, Removable Storage
Class & Extension are basically “Catalogs”
- Extension : “I implement this contract” (e.g. Launch)
- Class: describes the WInRT classes (a concrete implementation)
WinRT – Internals
An Application automatically implements the “Launch contract”.
System queries the extension catalog to find the right extension. Explorer.exe queries the extensions catalog, checks if it’s the right object to activate, and activates it. Activation means : a request is sent to RPCS, which checks if the process is already running or not, sends request to DCOM launch service (which runs as System) and the app is started.
Sébastien explains how the WinRT base works and that is has a couple of layers before projecting itself into a language. He shows a sample C++ application that uses WinRTComponent() and shows the various methods and vtable breakdown that is part of objects used in the sample application. He moves to the asm listing for the application and shows the instructions used to reference virtual function pointers from the vtable.
Windows Store
Kevin jumps in and explains the purpose of the Windows Store. Microsoft decided to force you to go through the store to download WInRT applications. Signing is mandatory, so Microsoft will control all apps. When an app is verified by MS, you need to make sure
- it is linked with SAFESEH, DYNAMICBASE and NXCOMPAT
- it doesn’t hang or crash
- doesn’t use any forbidding API.
Of course, you can use shell coding tricks to find the base of an API and call it that way. Even if you can execute code (CreateProcess for example), everything still runs within the AppContainer context. It’s also important to know that you can’t prevent syscalls from being executed.
The AppContainer uses an additional PE flag.
Sandbox
A sandbox is a mechanism to isolate untrusted processes, Kevin explains. In most implementations, it will isolate a process that runs with limited rights, uses a broker that will execute specific actions for the isolated process. Sandboxing techniques use Restricted Tokens, Jobs, multiple Desktop/Workstations, and Low integrity levels (available since Windows Vista), preventing you to write to a higher-level integrity process and to change your privileges.
Chrome vs WinRT
Kevin continues by explaining why comparing both sandboxes is interesting. The Chrome sandbox is designed for security only, and the WinRT AppContainer is made for running applications.
Chrome uses a restricted SID, most of the SID groups are disabled and isolation relies on job and desktop (Windows XP) and integrity level (vista and up). Microsoft uses LowBox, which is a modified _TOKEN structure, and uses a new syscall NtCreateLowBoxToken to create a very limited token. The SepAccessCheck API was slightly modified to support the changed structure.
Chrome implements the broken and isolated processes within the same executable (chrome.exe) It uses some kind of fork() to differentiate, and implements its own access policies. LowBox, the MS implementation, uses COM.
From an IPC point of view, Chrome uses API hooking to easily sandbox a process (thru a closed source plugin) and performs checks on the parameters. The broker and the sandboxed process uses some shared memory. In LowBox, each request is a COM object and uses an ALPC port to transport marshaled COM objects (NtAlpcSendWaitReceive)
Conclusions
WinRT has a new design and new API. The technique relies on COM technology. The AppContainer provides some level of isolation, transparent to users & developers (implement ed inside the kernel), and the isolation is implemented in the kernel as well, which makes it easy to implement.
Interesting talk, good to see Microsoft is stepping up and providing easy ways to implement sandboxes in Windows 8.
© 2012, Peter Van Eeckhoutte (corelanc0d3r). All rights reserved.
Donate
Your donation will help funding server hosting.
