Last year I wrote an article about security considerations for ClickOnce deployments which can be found here. Since then some of the default behavior has changed – and not to the better IMHO. But first some history:

.NET includes the Code Access Security technology to protect us from untrusted code. This means that by default code that is coming from a file share or the internet (stand alone apps or browser controls) has limited access to local resources like the file system or the registry. Also other features of the Framework are “turned off” or heavily restricted like the ability to interop with Win32 or COM code or Reflection. The only way to relax these restrictions is to re-configure the runtime security policy. This is not hard, but requires extra steps. The defaults are quite secure.

On the other hand it is quite handy to be able to run code from remote location like the intranet, e.g. for central deployment of WinForms applications. In these scenarios the default CAS policy is far too restrictive for most applications to do anything useful.

This is an classic example of the tension between security and productivity or feature-richness.

It turned out that doing sensible policy design and the deployment of these policies to the client desktop was no easy task (a lot of times people just gave FullTrust to the Intranet zone – which defeats the purpose). Often this was harder than just starting a .MSI file on the client and doing a “fat client” install.

So Microsoft had a very good security technology in place, but not many people used it because it was too hard. For the 2.0 version of the Framework they came up with a trade-off solution – ClickOnce.

ClickOnce is a new deployment technology which – besides many other features – supports the automatic elevation of permissions on the client. What does that mean?

This means, that if an applications needs more CAS permissions than what would be granted by policy, the user is presented with a dialog and gets asked if he wants to elevate the permissions of the application – and this works up to full trust. So you might ask – why do we need CAS at all – if the user is allowed to “bypass” it anyway?? And this is where Microsoft made the security trade off – they relaxed the security restrictions but made permission elevation configurable by zone and publisher identity. That means you can enable elevation for the intranet zone (e.g. your local intranet based applications) but can disable elevation for code coming from the internet (e.g. the evil trojan horse). There are more configuration options, e.g. to only allow elevation, when the application comes from a trusted publisher (technically this boils down to a digital signature on the application’s manifest).

So far so good. Up to Beta 2 Microsoft chose the following defaut settings:

Intranet Zone & Trusted Sites: Permission Elevation allowed
Internet Zone: Elevation only allowed for applications signed by a trusted certificate with the “Code Signing” intended purpose.
Untrusted Sites: Permission elevation not allowed

This means that you can easily deploy applications that need elevated CAS permissions in your intranet, but applications originating from the internet have to have a trusted and valid signature. To get such a certificate you have to buy one from one of the CAs that are trusted by Microsoft/Windows (they come pre-installed in your local machine/trusted root CAs certificate store). If the CA does its job properly the identity of the cert applier gets checked and in an ideal world you could track down the publisher of every malware.

Microsoft changed this default behaviour in 2.0 RTM – it is now:

Intranet Zone & Trusted Sites: Permission Elevation allowed
Internet Zone: Permission Elevation allowed
Untrusted Sites: Permission elevation not allowed

Yes, that’s no typo – you can now elevate permissions from the internet zone by default and no certificate is required at all. The user will get presented a trust dialog and after clicking OK the program will be installed locally and executed. You can verify this behaviour by checking these two proof-of-concept ClickOnce apps:

WinForms App that allows to read arbitrary files on your harddrive: click!
WinForms App that does a demand for full trust and displays the outcome: click!

(are you afraid to click on these links?? – the source code is provided at the end of this entry and you can try it with your own server)

Do you like that?

Well – I talked to some people at Microsoft about these settings – one answer I got was (and I think that is a valid argument) :

“The elevated trust dialog is designed to be similar to IE’s dialog for launching a native app, given that it’s the same sort of trust decision.”

I can totally agree with that – security is often about consistency and giving the user a certain confidence that he is doing the right thing. But then I wonder why IE (like other popular browsers) still allow to start executables directly from the internet – but I guess this discussion is out of scope.
But I think we are starting something “new” here (=managed code), so we could do better than mimicking the unmanaged world.

Another argument, and that’s more towards the trade-off solution I talked about earlier was, that if ClickOnce would be too hard/restrictive, this would be an “adoption blocker” again (like NTD/standard CAS was).

Well – companies have done their best in the past years to block all kinds of executables at the network perimeter – and if they become aware that with the installation of .NET 2.0 they introduce a new type of executable (the .application file), the same will happen here, too. That’s what I call “adoption blocking”.
In addition to that, security people at companies will not like this at all and just give them another argument why Microsoft technologies are not secure.

Home users or corporate laptops which are operated outside the perimeter and edge services are on their own here.

And what just doesn’t seem to fit into this picture at all, .NET 2.0 disables NTD for the Internet zone, which would result in a much more restricted sandbox whithout the ability to elevate permissions at all (read more here).

Call me pessimistic – but sooner or later someone will try to exploit that – and this will be no good press for .NET/Microsoft.

A word about trusted applications
ClickOnce features the notion of a “trusted application” – technically that means that the certificate used to sign the manifest is also imported into the “trusted publisher” certificate store. Trusted application totally bypass the elevation/trust prompt and get whatever permissions they like – so even if you set permission elevation to “disabled” for a zone – trusted applications will be able to elevate.
If being paranoid you could think of an attack vector where a trojan/virus could add certificates to that store and subverts ClickOnce settings. Of course – if malware is able to those modifications to your system you are in trouble anyway.

So I haven’t found a way to completely disable ClickOnce by zone. Which I think should be possible – and again – if admins will not find a way to do that – they will just delete the “.application” extension mapping (–> “adoption blocking”).

I propose the following prompting behavior:

Intranet Zone & Trusted Sites: Elevation only allowed for applications signed by a trusted certificate with the “Code Signing” intended purpose.
Internet Zone & Untrusted Sites: disabled

This would allow to easily deploy signed applications in your intranet and disable permission elevation from the internet and untrusted sites – but you could still use the trusted publisher feature to run applications from these zones.

So what to do next?
Make sure you understand the implications of the ClickOnce default settings. You can configure this behavior in the registry. I provide some .reg files to lock down the prompting behavior that you can import. I also wrote an administrative template that can be used to centrally distribute theses settings via Active Directory Group Policy objects. Furthermore educate your users that they should never run executables directly from the internet if they are not 100% sure about what they are doing.

Am I too paranoid? What do you think?

Resources:

• Locked down TrustManager settings
• Getting Certificates for Intranet trusted Applications
• Distributing Certificates in Active Directory
• Centrally deploy TrustManager settings
• Proof of Concept ClickOnce app
• ClickOnce Forum