views:

3053

answers:

6

I recently joined a firm and when analyzing their environment I noticed that the SharePoint web.config had the trust level set to Full. I know this is an absolutely terrible practice and was hoping the stackoverflow community could help me outline the flaws in this decision.

Oh, it appears this decision was made to allow the developers to deploy dlls to the Bin folder without creating CAS policies. Sigh.

Just want to clarify and make matters worse, we are also deploying third party code to this web application.

+2  A: 

Flaws? Many. But the most damning thing is straight out of the CAS utility:

"...it allows full access to your computer's resources such as the file system or network access, potentially operating outside the control of the security system."

That means, code granted Full Trust can execute any other piece of code (managed or otherwise) on the system, can call across the network to any machine, can do anything in the file system (including changing permissions on restricted files - even OS files).

Most web programmers would say "that's not a problem, it's just my code," which is fine.... until a security flaw crops up in their code that allows an attacker to use it to do unsavoury things. Then previously-granted Full Trust becomes quite unfortunate.

DannySmurf
Don't confuse .NET's code security concept of Full Trust with Windows authorization. Setting Full Trust doesn't grant any new rights to the ASP.NET worker process's account. Windows will still e.g. limit access rights to the file system in accordance with DACLs etc.
Barry Kelly
True, but with Full Trust an assembly with high-enough Windows credentials (given the lax CAS policy, that's the first thing I'd look for if I were reviewing this app....) can simply start changing DACLs too.
DannySmurf
Eh... no. Do you think that e.g. the guest account can simply modify permissions on OS files and start writing randomly? Have you ever encountered problems in practice with iusr accounts?
Barry Kelly
Not personally, but I'm not talking about a guest account. Given how lazy they seem about security, the FIRST assumption I'd make is that the ASP.NET account is also running with elevated privileges within the OS. Of course, that discounts an escalation attack, which is also a real possibility.
DannySmurf
+1  A: 

If they're ignoring the CAS policies, it might be a tough sell to get them to dial it back, since it makes their job a little harder (or, at least, a little less forgiving). Changing security practices is always tough - like when I had to convince my boss that using the SA accounts in the SQL connection string of our web applications was a bad idea - but hang in there.

Full Trust allows the application to escalate to control of any resource on the computer. While you'd have to have a security flaw in your application to allow these, and they'll probably claim that they've prevented any escalations through astute programming, remind them that in the case that something happens, wouldn't they rather the web application didn't have control of the whole computer? I mean, just in case?

EDIT: I was a little overzealous with my language here. Full Trust would allow the application to control whatever it wants, but only if the Application Pool process has sufficient rights to do it. So if you're running as a limited user with no rights on the server except what the applicaition needs, then I suppose there's essentially no risk to "Full Trust". The reality is that the app pool owner most likely has a number of rights you wouldn't want your app to have (and in some cases, many, many more), so it's much safer to limit app security and grant additional rights needs individually to the application. Thanks for the correction, Barry.

rwmnau
"escalate to control of any resource" is far too strong language. Full Trust code security is independent of and subservient to Windows security. The ASP.NET worker process's rights are limited to those of the user that owns the process. Full trust can't and doesn't grant extra rights here.
Barry Kelly
+1  A: 

I honestly have found sharepoint to be too restrictive.

Take a look at the following page to see what can and cannot be done based on trust levels http://msdn.microsoft.com/en-us/library/ms916855.aspx

One problem I ran into immediately was I could not use the Caching Application Block. We were using this application block instead of the ASP.NET caching because we had used an MVP pattern and may open up a win forms application.

Another problem is no reflection, this caused the About page to fail because the version number is pulled from the metadata of the assembly.

I think the best solution is to not use Sharepoint as an application host. I would only use Sharepoint as an application host if the amount of coding was so small that it didn't affect the trust level and it would be less work then setting up a new application. If you are doing some type of coding which is starting to hit the walls of the trust level, move your application into a proper ASP.NET enviroment. But that is just me, and I am biased. Maybe you should try to aim for a Medium trust level compromise.

Bob
If you work with SharePoint againSharePoint's default trust level can be changed in the web applications's web.config. The default is just that, a default.
Tom Resing
Sometimes when working with large organizations with large Sharepoint farms they will have their own policies which prevent any changes to defaults. The typical reason for this is that they are running so many instances, they want everything configured the same way and with as little setup as possible. So change the default isn't always an option.
Bob
+1  A: 

Todd,

The book, "Programming Microsoft ASP.Net 3.5", by Dino Espisito provides some sound reasoning for not allowing Full Trust in ASP.Net applications.

Among other reasons, Dino states that web applications exposed to the internet are "one of the most hostile environments for computer security you can imagine." And:

a publicly exposed fully trusted application is a potential platform for hackers to launch attacks. The less an application is trusted, the more secure that application happens to be.

I'm surprised the StackOverflow community did not outline the problem with Full Trust better. I was hoping for the same thing so I didn't have to go digging through my pile of books to find the answer, lazy me.

Tom Resing
A: 

Hey guys!.. i just asked my shared webhost about some security issues i had with running an MVC application (ReflectionPermission failed).. and then the support team simply set my application trust level to "Unrestricted", even though i told them not to do this.

Does this mean I can do all kinds of nasty stuff on the shared web host now?.. Not that I intend to do this, but what if some hacker on the same server is also granted "unrestricted" trust level?.. seems like a bad idea to me, or is it OK?

I'm just wondering about the security implications of unrestricted trust levels on a shared webhost.

You should ask this as its own question, then you will get an answer.
Alex Angas
+1  A: 

I use full trust on my development machines.. so I can deploy to the BIN when building new code. I trust my own code and run it in the GAC on production because creating CAS policies is a pain.

The third party thing would have me worried.. however:

Most 3rd party solutions found on the web also deploy to the GAC (assuming for the same reasons). This gives them all rights regardless of trust level. Feels like it has more to do with if you trust the 3rd parties or not.. and do you really trust your own developers?

What would a hacker do? The scenario where a hacker drops an evil dll in your BIN folder I don't see as very realistic.. regardless if he can do that he can also probably change the trust level.

ArjanP