There is quite a lot of talk recently about the dangers of fully trusted code. i can only agree.
- Invoke private Methods using Reflection
- Execute Methods in other AppDomains
- Call Assert..or even turn of CAS all together for the current process
Isn’t that kinda scary?
The CLR provides very powerful mechanisms for sandboxing code, e.g. loading code in question in a second (partial trust) AppDomain and use the CrossAppDomainChannel to communicate with this code (think of a plugin-type scenario). If you are at WinDev this year – check out Robert Hurlbut’s talks about writing least privilege apps and hosting code in secure AppDomains.
Microsoft doesn’t make it easy for us to design and test partially trusted code nowadays. This will get better in .NET 2.0.
One interesting aspect of this problem that merely noone seems to be aware of are fully trusted ASP.NET apps. ASP.NET Web Applications and Services (ASPX & ASMX) are fully trusted by default. So what – you might think…
- Call out to unmanaged code, e.g. RevertToSelf (e.g. if impersonation is enabled, you can revert back to ASPNET or the worker process identity)
- Reading and reflecting against assemblies of other web applications in the temporary ASP.NET folder
- Spawning new processes via WIN32, WSH or WMI
- Reading other web sites Metabase entries, e.g. the anonymous user and impersonate them (Metabase entries are ACLed so that IIS_WPG can read them by default)
- Search the process space for Windows Tokens (e.g. from other web apps running in the same process but different AppDomains), grab them and impersonate.
This is especially important if you are sharing the Web Server with other parties (shared hosting environment, e.g. at ISPs or corporate Web Servers) – but also if you want to reduce the attack surface of a ASP.NET App/Service to minimize the risk of misuse.
.NET 1.1 introduced the possibility to run ASP.NET AppDomains in partial trust There are some pre-defines trust levels like full, high, medium and low which can be applied globally through machine.config or a per WebApp in web.config. Check out the brilliant “Threats and Countermeasures Paper” on the MSDN Patterns & Practices site for in-depth information, especially chapter 9.
Simply by adjusting the trust level to high resolves most of the problems, e.g. calling out to unmanaged code. cool – you may think. So ISPs only have to adjust the trust level in machine.config and everything is safe…
Unfortunately it is not that easy –
Even with partial trust you can still e.g. read from the temporary ASP.NET folder, but there is also some important stuff that won’t work anymore – e.g. using OLEDB Providers.
Local Access Databases are the only easy way to do data driven Web Sites in shared hosting environments (the security of this solution is another story – if you are in doubt – try to access the .mdb file directly through your browser and see if it is downloadable). But this won’t work anymore if the app doesn’t have permissions to use OLEDB.
At first glance this only looks like you have to create a custom policy file and add the required OleDbPermission (as described in Threats and Countermeasures) – but the problem is buried deeper in the Runtime. The OleDb class not only demands the OleDbPermission but also has a Full Trust Link Demand. The only way to circumvent this problem (again described in TaCm) is to sandbox your database access code in the GAC with Full Trust and APTCA..again no solution for a shared hosting environment. So we are stuck here.
The SQL Server Provider runs fine in partial trust. So maybe with the advent of SQL Server 2005 and xcopy-deployed MDF files the situation will get better.
Another problem is, that not all framework libraries are allowed to be called by partially trusted code. Check out the above mentioned Keith Brown article for a list and his FindAPTC tool. WSE2 e.g. will not work in partial trust.
But if you have to share the server machine you should definitely demand a partial trust level as well as a W2K3 box (because of the worker process mode isolation), a seperate worker process (App Pool) and a seperate worker process account – but even then the admin of the box can do a vast array of misconfigurations that prevents a clean separation of the applications (NTFS and Metabase ACLs, location of temporary assemblies a.s.o).
If you want to experiment or test how much permissions/privileges your application has, i can recommend the OWASP tools – all available from http://www.owasp.org/software/dotnet.html
- ASP.NET Security Analyzer (ANSA)
- ASP.NET Baseline Security (ANBS)
- Security Analyzer for Microsoft Shared Hosting Environment (SAM’SHE)
- ..and a very good whitepaper about this topic (Secure Shared Hosting with IIS5)
aah – and btw – the first commercial product that came across my way that runs in partial trust by default is Microsoft’s SharePoint Portal Server 2003 (which makes extensive use of 3rd party plugins called WebParts….)
Some further information/links about this topic:
- Robert Hurlbut on Partial Trust
- Maxim Karpov – Guilty until proven innocent
- Setting MetaBase ACLs
- Changing the location of temporary ASP.NET files (see under debug)
- OWASP Mailing List (recommended!)