Microsoft Windows Security: Application Manifests and Assemblies

In this blog/article we discuss two concepts that are intertwined in their usage and implementation. First we discuss 'Assemblies' and the challenges brought by assemblies to the table, followed by the solutions and how Application Manifests are the key component to that solution.

Assemblies

When speaking about assembly we normally refer to .dll files. An assembly can consist of multiple types of files which may be needed by an executable at run time. Microsoft define assembly as follows: "An assembly is a collection of types and resources that forms a logical unit of functionality. All types in the .NET Framework must exist in assemblies; the common language runtime does not support types outside of assemblies. Each time you create a Microsoft Windows® Application, Windows Service, Class Library, or other application with Visual Basic .NET, you're building a single assembly. Each assembly is stored as an .exe or .dll file."

The Problem of Shared Assemblies

The resources contained in Assemblies were shared between different applications. This gave rise to the possibility that if an assembly (dll file or a collection of similar resource files) is updated by an installer, it may not be backward compatible.Example: An application name ‘app1’ depends on ver 1.0 of a some.dll which is part of an assembly. When a new installer installs an application ‘app2’ which also depends on some.dll it will install the latest version of some.dll ver 2.0.
It is possible that the new updated version is not backward compatible and has removed some functionality from some.dll, which was needed by app1. This will cause the app1 to stop functioning a.k.a this will break app1.

The solution of side by side technology

This problem has been solved in Windows using side-by-side technology , Side-by-Side technology allows two different versions of assemblies to exist on the same OS installation. One assembly will contains some.dll ver 1.0 which will be accessed by app1; whereas app2 will access some.dll ver 2.0.

For Side-by-side existence of two assemblies the additional versions are placed in %Systemroot%\WinSxS

How are assembly dependencies related to application manifests ? The information about a dependency is written in an application’s manifest.

Application Manifest

An application manifest is information about an application for the OS, regarding the execuatbles dependencies, what the app expects from the OS in terms of context and environment.

A manifest is an XML the schema for the XML of a manifest file can be found at : http://msdn.microsoft.com/en-us/library/aa375635%28v=vs.85%29.aspx

The manifest of an application (executable) can be acquired using one of the sysinternals tools named ‘sigcheck’ using the following command:

C:\Windows\system32\>sigcheck -m notepad.exe

-------------------snippet 1 - Application Manifest of notepad.exe ---------

----------------------------snippet starts here -------------------------

Verified: Signed

Signing date: 4:59 PM 8/22/2013

Publisher: Microsoft Windows

Description: Notepad

Product: Microsoft® Windows® Operating System

Prod version: 6.3.9600.16384

File version: 6.3.9600.16384 (winblue_rtm.130821-1623)

MachineType: 64-bit

Manifest:
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assemblyIdentity

name="Microsoft.Windows.Shell.notepad"

processorArchitecture="amd64"

version="5.1.0.0"

type="win32"/>

<description>Windows Shell</description>

<assemblyIdentity

type="win32"

name="Microsoft.Windows.Common-Controls"

version="6.0.0.0"

processorArchitecture="*"

publicKeyToken="6595b64144ccf1df"

language="*"

</dependentAssembly>

</dependency>

</requestedPrivileges>

</security>

</trustInfo>

</windowsSettings>

</application>

</assembly>

----------------------snippet ends here---------------

Note: In the snippet above, the manifest is only the part that is in XML, the file information before it is not part of a the manifest.

In the manifest an application can declare it’s dependencies and the exact versions. The manifest contains the version of windows this app was developed for. So that the operating system can provide it that behavior based on this parameter. Basically it checks the application requirements so that the application does not break/crash. This includes the OS and run time libraries that may be required by the application.

Required Token (requestedExecutionLevel)

In windows vista the manifest also contains the requestedExecutionLevel attribute. This attribute is ignored in windows XP and previous versions. In the example notepad.exe manifest shown above the requestedExecutionLevel is set to "asInvoker". So the notepad.exe's access token will depend on who invokes it. If a normal user runs notepad the access token will belong to the user, if it started using 'Run as administrator' the access token will belong to the administrator or will have a high integrity label.

For an application like windows/system32/mmc.exe administrative privileges are required, therefore if we look at the requestedExecutionPrivelege attribute in the manifest of mmc we see it is set to "highestAvailable".
This means that the tokens available to a user the highest possible one should be used. In vista, for users who are memebers of the local admin group have two tokens, a filtered token and a privileged token. If a normal user starts an administrative application like mmc.exe User Access Control (UAC), prompts the user for consent, or for the administrator's credentials on the system.

Below is the (embedded) manifest for the windows/system32/mmc.exe application:

--------Snippet 2 - Application Manifest for mmc.exe--------------

----------------- snippet starts here-----------------------------

Verified: Signed

Signing date: 4:55 PM 8/22/2013

Publisher: Microsoft Windows

Description: Microsoft Management Console

Product: Microsoft® Windows® Operating System

Prod version: 6.3.9600.16384

File version: 6.3.9600.16384 (winblue_rtm.130821-1623)

MachineType: 64-bit

Manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assemblyIdentity

processorArchitecture="amd64"

version="5.1.0.0"

name="Microsoft.Windows.MMC"

type="win32"

<description>Microsoft Management Console</description>

<requestedExecutionLevel level="highestAvailable" uiAccess="false"

</requestedPrivileges>

</security>

</trustInfo>

<asmv3:application>

<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">

<dpiAware>false</dpiAware>

</asmv3:windowsSettings>

</asmv3:application>

</assembly>

--------------------- snippet ends here-------------------------

Manifest Storage

Manifests is xml embedded in a .dll or .exe file. Or they can be external files. If an application app1.exe has an external manifest then that manifest needs to be named app1.manifest.

It is not mandatory for applications to have a manifest (as of windows 8.1), but it is mandatory for .dll files if the .exe did not specify any MS VC runtime environment number.

About the Author: Saquib Farooq Malik, is a senior Information Security Consultant at ITButler e-Services(www.itbutler.com.au) . Saquib Specializes in Vulnerability Assessment and Penetration Testing, implementations of ISO 27001 in different corporate environments in the Middle East.

He is a CISSP, an ITILv3 Foundation certified professional, ISO 27001 Lead Auditor, Tenable Certified Nessus Auditor and a Lumension Certified Engineer.

Microsoft Windows Security

Monday, January 20, 2014

Application Manifests and Assemblies

Assemblies

Application Manifest

Required Token (requestedExecutionLevel)

Manifest Storage

No comments:

Post a Comment