Understanding the Issues of Using APTCA

As you know, the .NET Framework can protect certain resources, such as files or registry keys, from being accessed in managed code. Normally, an assembly that has a strong name and is fully trusted cannot be called by code that is not fully trusted ”also known as partially trusted code ”because the CLR automatically adds a link demand for the FullTrust permission on all public members in the assembly. This means only fully trusted callers are allowed to call the assembly. However, there are times when an application might want partially trusted code to call into the fully trusted code.

For instance, imagine you have a Web application that allows third-party customers to extend functionality by using your product s fully trusted assembly, which is installed in the GAC. Although you could require the customer to install the third-party code into the GAC, doing so means that they must trust that those assemblies won t do anything harmful to the system because code in the GAC has a lot of privileges. Instead, you might create a directory that is granted limited permissions in which third-party components can be installed. For those components to still be allowed to use your FullTrust assembly, your fully trusted and strong-named assembly must use the AllowPartiallyTrustedCallers attribute (APTCA) to suppress the link demand for the FullTrust permission.

Then, not only might your managed assemblies contain security flaws, but using APTCA allows partially trusted callers to call into your FullTrust assembly ”meaning your code is more vulnerable to attackers . For example, an assembly that does not have file access might be able to use another assembly marked APTCA that does grant file access, allowing the assembly to be repurposed by the attacker. This type of attack is also known as a luring attack . Figure 15-12 shows how a partially trusted assembly attempts to access a file. As discussed earlier in this chapter, normally the CLR does not allow the partially trusted assembly to call the fully trusted assembly.

Figure 15-12: Partially trusted assembly calling into an assembly marked APTCA

In this example, CAS prevents the luring attack because it checks whether Assembly B has permission for file access, and when that check passes , it checks next whether Assembly A has permissions for file access. The check fails because the partially trusted assembly doesn t. However, recall the earlier discussion on stalk walk modifiers. Can you think of any ways that Assembly B can modify how CAS does the stack walk to grant file access permission to Assembly A? Assembly B could assert file access, which would stop the stack walk from checking whether Assembly A has permission, as shown in Figure 15-13.

Figure 15-13: Fully trusted assembly marked APTCA asserts file access permission, allowing partially trusted assemblies to use the File API.

Also, the assembly might use only a link demand to protect the public method from being called. However, as discussed earlier, link demands can be bypassed. Figure 15-14 shows how Assembly C uses a link demand to ensure the caller has the needed permissions to perform an operation. Assembly B, which is marked APTCA, could wrap the operation in a public method that Assembly A could call. In this example, the partially trusted assembly is able to avoid the link demand and could potentially repurpose Assembly B to attack the system.

Figure 15-14: Fully trusted assembly using a link demand to check permission is bypassed when an assembly marked APTCA allows a partially trusted assembly to use the File API.

One of the biggest misconceptions about this type of luring attack is that it is difficult for an attacker to get a user to execute partially trusted code on the victim s machine. After all, an attacker can t place malicious code on the victim s machine without the consent of the user or administrator, correct? Not exactly true! Walk through an example of how this can be done:

You install an application that installs an APTCA assembly into the GAC.
The APTCA assembly has a public method that allows it to write to a file on the hard disk drive that is used to store your music playlist of a given name.
That method does a declarative assert for the FileIOPermission using the Write security action so that any callers can also create the playlist file as expected, meaning the assert is scoped at the method level.
A malicious attacker realizes this common APTCA assembly has this public feature that writes the playlist file to the hard disk, but the public method appears that it only writes to a special path . After some further investigation, the attacker discovers there is a canonicalization bug (refer to Chapter 12) when the playlist name is specified that allows the attacker to write to any file or folder on the hard disk. Now, the attacker crafts the exploit.
The attacker creates a Windows UserControl using the .NET Framework. In the constructor, the attacker calls into the APTCA assembly to write a file of choice to the hard disk.
The attacker then sends you a link to the attacker s Web site and lures you into browsing to it ”with a little bit of social engineering, this isn t as hard to do as you might think.
Upon visiting the malicious Web site, your browser automatically downloads the assembly containing the UserControl and instantiates the control by calling its constructor. Normally, a UserControl is run with very few privileges, especially without the FileIO-Permission.
The attacker s code in the constructor calls into the APTCA assembly, which asserted the FileIOPermission for write access, and the attacker can now write files to any place on your hard disk ” not good ! This bug might seem like a bug in the browser, but it is actually a bug in the APTCA assembly because it granted too many permissions to partially trusted code. Figure 15-15 illustrates how this happens.

Figure 15-15: APTCA assembly being loaded by a UserControl hosted in a browser, which allows an attacker to write any file to the victim s machine

To understand this attack, consider why it actually works. First, any partially trusted code can call into an APTCA assembly. If no demands are done, the partially trusted code will have permissions to execute code. If the APTCA assembly does not assert the FileIOPermission, the demand for the FileIOPermission would not have been stopped from reaching the attacker s assembly, thus preventing him in using the File API.

You might wonder how the code was even executed in the first place. Internet Explorer is capable of loading .NET UserControls into the browser, but normally these controls are granted the Internet permission set, which includes the Execute permission and a few more. The UserControl is automatically downloaded from a server and loaded in a Web page using the following syntax:

 <OBJECT CLASSID="nameof.dll#namespace.class">

If the assembly is not already installed on the victim s machine, it will be downloaded automatically as long as the DLL is located in the same folder as the Web page that caused it to load. The assembly can reference the APTCA assembly and just call its public methods . Do you think the browser will prompt the user to execute the assembly? Not in all cases, and even if it does, many people simply click Yes in most dialog boxes. As for managed controls, there is no prompting model; they either run or are blocked.

If your application has an APTCA assembly, look hard for luring attacks. This can be an extremely tedious and time-consuming task. Here are the questions to ask if your assembly is marked with APTCA:

How do you determine if an assembly is marked APTCA?
Why is the assembly marked APTCA?
What functionality does the public interface provide?

Determining If an Assembly Is Marked APTCA

An assembly is marked APTCA by using the AllowPartiallyTrustedCallers attribute, so you could search the source for that string. It is declared using the following syntax:

 [assembly: AllowPartiallyTrustedCallers]

Alternatively, if you don t have access to the source code, you can use Microsoft IL Disassembler (ILDASM), which is included in the .NET Framework Software Development Kit (SDK), to look at the manifest information of the assembly. Figure 15-16 shows the manifest information for an APTCA assembly.

Figure 15-16: Using ILDASM to see manifest information for an APTCA assembly

Understanding Why the Assembly Is Marked APTCA

Really question why the assembly is marked APTCA, which by definition means that you intend for partially trusted callers to be able to use your assembly. If possible, APTCA assemblies should be avoided because they increase your attack surface and are challenging to test thoroughly.

Understanding What Functionality the Public Interface Provides

If your application must have an APTCA assembly, carefully review the functionality that is available for an attacker to call into. For instance, FormatDrive should raise a huge flag if it is a public method on an APTCA assembly; however, that likely won t happen. Think about what the method does and whether an attacker can potentially repurpose it for malicious uses. Refer to Chapter 18, ActiveX Repurposing Attacks, and Chapter 19, Additional Repurposing Attacks, for more information on repurposing attacks.

Also, often methods are marked with the public or protected access modifier because another class in the same assembly needs to use it. On the other hand, if the method is really intended only to be called by the same assembly, the method should be marked with the internal access modifier so it isn t visible to other assemblies ”unless the other assemblies can use Reflection Permission , which is considered a high-privilege permission that should be granted only to trusted callers.

Testing for Luring Attacks

As mentioned earlier, testing APTCA assemblies can often be a tedious and time-consuming task. There really aren t any tools that will indicate whether a method can lead to a luring attack. Instead, you need to find all of the places that attackers can call an APTCA assembly, and then determine whether a luring attack bug is present. Here are the basic steps to help you determine whether a luring attack bug exists:

Look for all the public objects on the APTCA assembly.
For each public interface, see if any permissions are being asserted. If so, this is an indicator that the method needs more attention because it is vouching for some permission for a partially trusted caller ”which can potentially be attacker-supplied code. Methods that assert should also demand another permission.
For each public interface, determine whether there is any protection on calling the interface by using a link demand or a full demand. The permission that is being demanded shouldn t be too generic where the attacker s code might already be granted the case.
If the public method is using a link demand, see if the demand could be bypassed using the techniques discussed in the section Finding Problems with Link Demands.
Even if the public method might be demanding a permission, make sure no other callers expose the public method and end up granting the permission. For example, if the public method Class1::Foo() does a full demand for Permission X and public method Class2::Bar() ends up asserting Permission X, a vulnerability exists.
After checking all of the public interfaces and the call stack to see what an attacker has permission to access, think about what the attacker can do. Remember, a permission is used to protect a resource. If the attacker can gain access to the resource or cause a victim to perform operations, a luring attack bug exists that must be fixed.

You can also run the security FxCop rules on managed assemblies, which can catch most of the issues with an APTCA assembly. Luring attacks are a real security threat. Often, we have seen improper use of CAS that could lead to security bugs .

Note	The .NET Framework 2.0 introduces a feature called security transparency that helps reduce a lot of the APTCA problems mentioned above, and is great for ensuring the code is running with the least privileges.