Nigel Watling

July CTP and www.netfx3.com sandbox

2006-07-18T01:49:00Z

At last! The .NET Framework 3.0 - July 2006 CTP has arrived. This is the drop we've all been waiting for. The issues with the Windows CardSpace in the June CTP have been fixed. If you want to experiment with CardSpace there is no better build to install and play with. This build is fom the RC1 fork so changes from this point on should (<insert normal disclaimer>) be few and far between.

Targeting this build, the nice people at Telligent have added Information Card support to Community Server 2.1 for our community site, http://wcs.netfx3.com. If you browse to http://sandbox.netfx3.com using IE7 Beta 3 and you have the July CTP installed you will be able to use Information Cards to register and logon to the site.

We're currently using a standard SSL certificate with the sandbox so when the CarSpace Trust Dialog pops up you will not see any logos and you will be warned that it is not a High Assurance SSL certificate:

"This site does not meet Windows CardSpace requirements for a bank or major Internet business..."

This illustrates the value of High Assurance certs and their integration with CardSpace. If a website uses an HA cert users who login using Information Cards can have a high(er) degree of confidence in the identity of the site - it meets a higher verification bar at the Certificate Authority.

Furthermore, if a bad guy attempts to phish users by drawing them to a site copying the genuine site, the user will spot something fishy (sorry!) because either there is no way to logon using CardSpace or, if there is, the user will be warned 1) that it's the first time they've visited the site (CardSpace keeps track of where cards are used), and 2) that it isn't an HA cert - provided the HA cert verification mechanism is working as intended, that is.

We will be adding an HA cert to the sandbox in future so you will be able to test the HA cert behaviour as well.

Using MetadataResolver with Windows CardSpace and WCF - June CTP edition

2006-06-17T04:15:00Z

Since the .NET Framework 3.0 June CTP should soon be upon us here is the updated version of the MetadataResolver code I gave in the last post. You'll see that it's a bit more concise and there is no longer a separate InfoCardClientCredentials class.

One thing to be aware of when you build a service with post-beta 2 bits is that mex is no longer on by default so you'll need an additional service endpoint for this code to actually be able to pull down mex from you WCF service:

I won't put all the code here but we'll be updating our code samples at http://wcs.netfx3.com when the June CTP hits the streets. You should also keep an eye out for some new features on the site to celebrate this build!

using System;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.ServiceModel.Description;
using System.IdentityModel.Selectors;

namespace HelloClient
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Press <Enter> when service is ready");
            Console.ReadLine();
            try
            {
                Uri mexUri = new Uri("http://localhost:4124/helloService/mex");
                ContractDescription contract = ContractDescription.GetContract(typeof(HelloService.IHello));

                EndpointAddress mexEndpointAddress = new EndpointAddress(mexUri);
                ServiceEndpointCollection endpoints = MetadataResolver.Resolve(contract.ContractType, mexEndpointAddress);

                foreach (ServiceEndpoint endpoint in endpoints)
                {
                    if (endpoint.Contract.Namespace.Equals(contract.Namespace) && endpoint.Contract.Name.Equals(contract.Name))
                    {
                        ChannelFactory<HelloService.IHello> cf = new ChannelFactory<HelloService.IHello>(endpoint.Binding, endpoint.Address);
                        cf.Credentials.ServiceCertificate.Authentication.RevocationMode = System.Security.Cryptography.X509Certificates.X509RevocationMode.NoCheck;
                        HelloService.IHello chn = cf.CreateChannel();
                        Console.WriteLine(chn.Say());
                        cf.Close();
                    }
                }
            }
            catch (UserCancellationException)
            {
                Console.WriteLine("User cancelled");
            }
            catch (UntrustedRecipientException)
            {
                Console.WriteLine("User does not trust the recipient");
            }
            catch (ServiceNotStartedException)
            {
                Console.WriteLine("CardSpace service not started");
            }
            catch (InfoCardException ice)
            {
                Console.WriteLine("Generic CardSpace exception :" + ice.Message);
            }
            catch (Exception e)
            {
                Console.WriteLine("Other exceptions :" + e.Message);
            }
            finally
            {
                Console.WriteLine("Press any key to finish");
                Console.ReadKey();
            }
        }
    }
}

Using MetadataResolver with Windows CardSpace and WCF

2006-06-15T03:15:00Z

If you want to use CardSpace from a WCF client without hard-coding config or using an App.config file then try using the MetadataResolver class. Here is some code that works with .NET Framework 3.0 Beta 2 ("WinFX"):

I've been meaning to get a MetadataResolver example working for a while and I was finally able to spend some time today with it. Not too difficult although it's due to change a little bit with the June CTP. The revocation check was necessary to get around my certificate CRL being unavailable.

using System;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.ServiceModel.Description;
using System.IdentityModel.Selectors;

namespace HelloClient
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                Uri mexUri = new Uri("http://localhost:4123/helloService/mex");
                EndpointAddress mexEndpointAddress = new EndpointAddress(mexUri);
                ServiceEndpointCollection endpoints = MetadataResolver.Resolve(mexEndpointAddress);

ContractDescription contract = ContractDescription.GetContract(typeof(HelloService.IHello));

                foreach (ServiceEndpoint endpoint in endpoints)
                {
                    if (endpoint.Contract.Namespace.Equals(contract.Namespace) && endpoint.Contract.Name.Equals(contract.Name))
                    {
                        ChannelFactory<HelloService.IHello> cf =
                            new ChannelFactory<HelloService.IHello>(endpoint.Binding, endpoint.Address);

                        InfoCardClientCredentials credentials = new InfoCardClientCredentials();
                        credentials.ServiceCertificate.Authentication.RevocationMode = System.Security.Cryptography.X509Certificates.X509RevocationMode.NoCheck;
                        cf.Endpoint.Behaviors.Add(credentials);

                        HelloService.IHello chn = cf.CreateChannel();
                        Console.WriteLine(chn.Say());
                        cf.Close();

                    }
                }
            }
            catch (UserCancellationException)
            {
                Console.WriteLine("User cancelled");
            }
            catch (UntrustedRecipientException)
            {
                Console.WriteLine("User does not trust the recipient");
            }
            catch (ServiceNotStartedException)
            {
                Console.WriteLine("CardSpace service not started");
            }
            catch (InfoCardException ice)
            {
                Console.WriteLine("Generic CardSpace exception :" + ice.Message);
            }
            catch (Exception e)
            {
                Console.WriteLine("Other exceptions :" + e.Message);
            }
            finally
            {
                Console.WriteLine("Press any key to finish");
                Console.ReadKey();

}

}
}
}

Least privileged user access for developers

2005-07-30T00:12:00Z

OK, the last entry was a teaser for a blog entry or two on what developers can and IMHO should do regarding least privilege and least privileged user access (LUA) on Windows. A lot of this information can be already found scattered around but I wanted to target developers specifically and also be reasonably concise with links to furhter information.

Principle of Least Privilege (from Writing Secure Code): “All apps should execute with the least privilege to get the job done and no more”

The idea of least privilege is to limit the damage done by accident, error or attack. It’s quite simple: the more privileges a process has the more havoc it can wreak on your machine.

During Mark Russinovich’s entertaining and insightful malware talk at TechEd EMEA he admitted to accidentally downloading some spyware (which proved remarkably obstinate to remove). When Mark asked the audience who personally had been infected by malware, almost the entire room (~700 people) raised their hand. I have to admit I was surprised. If someone as smart as Mark Russinovich gets infected then what hope is there for the rest of us? The numbers in the room provided ample evidence: not a lot!

Given that we all make mistakes, all software has bugs, and that there is no shortage of hackers and malware, we’d be foolish not to apply the principle of least privilege to our PCs and to our code, right? What’s more, if we can do this with little or no inconvenience to either ourselves or our users then we’d have to be truly barking mad not to do something.

I am talking about developers here, not sysadmins, not knowledge workers (anyone else detest that term?), not home users. Developers are – of course – special and need special powers. They are continually installing tools and software, modifying registry entries, debugging, playing with COM and web apps and doing other fun stuff. What’s more, they have not only themselves to consider but also their software – and their users. Developers have the reputation of being anti-social but sandals and unwashed armpits and are nowhere near as offensive in my eyes as software which insists on running as SYSTEM when it doesn’t need to!

Let’s cover personal computer hygiene first and tackle code later. Here are the main choices, each making a different trade-off between security and usability:

The Developer as User choices
1) Log in as admin
2) Log in as admin but do risky things as LUA
3) Log in as LUA with a few extra privileges for added comfort
4) Login as LUA and escalate privileges when required
5) Login as LUA and stay there

Personally, I believe option 1 is indefensible and option 5 is impractical – at least until Windows Vista (née Longhorn)ships, where even admins log in as normal users – so let’s take a look at the other three.

Logging in as admin but doing risky things as LUA

The purists will pour scorn on this technique but given the large number of developers who admit to running as admin this can benefit a lot of people for minimal effort. You may resist all attempts to convert you to a non-admin logon but there’s really no excuse for not adopting this simple method of reducing risk, especially when you consider that much of today’s malware (rightly) assumes it will be running in an admin context and promptly fails otherwise.

You log in (as usual) as admin on your XP or W2K3 box but when it comes to running a browser, email, IM or any other app you deem risky, you cut the privileges using Software Restriction Policy (aka SRP or SAFER). There are two ways to do this:

1) You use a simple program which crufts up a restricted token using the SAFER APIs and then launches your chosen app using that token, or
2) You take the phone off the hook, put your feet on the desk and make like a sysadmin, running secpol.msc and using group policy

These approaches are documented by Michael Howard in Browsing the Web and Reading E-mail Safely as an Administrator, Part 1 and Part 2 respectively.

Part 1 has a simple app, DropMyRights, which you download, and then use as follows

DropMyRights {application path} [N|C|U]

N runs the app as a normal user
C runs the app as a constrained user (less rights than N)
U runs the app as an untrusted user (less rights than C)

N is the recommended setting and usually works. I find C sometimes works but U rarely does (eg. notepad doesn’t lauch!). Your mileage may vary depending on the apps you use so experiment and see what is best for you.

The obvious thing to do with DropMyRights is to set up some shortcuts for IE, IM and Outlook with a target such as

DropMyRights "c:\program files\internet explorer\iexplore.exe" N

To make it pretty, add a name like “IE (nonadmin)”, start the thing minimized and select an icon which entices you to click on it. Once you’ve replaced your old shortcuts with the shiny new ones you need never give it another thought. You are no longer running your risky apps as admin.

At this point, if you are a cynical old goat like me, then you will want to check that DropYourRights is doing what it says on the tin. To do this, download Process Explorer from Sysinternals.com and check it out: in the tool, double click the relevant process and in the Security tab you should see (at least) a Deny flag on the Administrators group and additional constraints for the C and U options.

Part 2 uses a magical DWORD registry key, Levels, set to 0x20000 under

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers

Once you have added this, you can run secpol.msc, go to “Software Restriction Policies” (it may ask you to create them via the action menu) and you will notice “Basic User” under Security Levels. You are then able to go to “Additional Rules” and add a new path rule, forcing an app to run as Basic User.

The advantage to this approach is that all shortcuts to that target path will launch as Basic User. Note you can use group policy to disallow certain apps from running. This can be extremely useful if there are certain pieces of software you don’t want running on your machine.

The ever-helpful kiwi, Michael Howard, provides an app, SetSAFER, which you can download and compile against a version of Visual Studio 2005. I’ve tried it with beta 2 and it works perfectly. SetSAFER provides a simple UI and an XML config file allowing you to avoid secpol.msc and manipulate the registry directly.

The observant amongst you may notice that when you add the Levels registry key some extra options appear for runas, namely /showtrustlevels and /trustlevel. This enables you to do the following:

runas /trustlevel:"Basic User" "c:\program files\internet explorer\iexplore.exe"

However, I’ve not had as much success with this (i.e. IE hangs) and I would advise you to use the other methods. This is a timely reminder that until the MSDN articles were published much of this stuff was undocumented so, as always, be careful.

Also please bear in mind the weaknesses of this whole approach (logging in as admin and running risky apps as least privilege). Malware running as LUA could send Windows messages to other apps running with higher privilege. However, you are raising the bar for the malware writers and contributing to a strategy of defense in depth.

Logging in as LUA but adding a few extra privileges

With this approach you make your everyday account a member of the Users group and then customize it by adding privileges that you need. You do this by running secpol.msc and going to Local Policies -> User Rights Assignment. You could, for example, give yourself the powerful SeSystemtimePrivilege which enables you to see a calendar by double clicking the clock in the toolbar (oops, I’m in danger of breaking the old journalist’s rule: never use sarcasm in writing). Actually, there is some method in the madness: you might not want end users to change the time on their machine as they could subvert auditing.

Personally, I don’t like this approach. Micromanaging your privileges is a labour-intensive PITA. The operating system is supposed to provide abstractions to avoid this kind of crap. Anyway, if you can keep the number of extra privileges low and it works for you then more power to you - but always remember that malware running as you can do everything you can.

Logging in as LUA and escalating privileges when required

This is the preferred approach from the LUA purists. You log on as a normal user (i.e. your user account is in the Users group not the administrators group) but when you need to you escalate your privileges. Ideally you should take only those privileges you need and relinquish them as soon as possible but to avoid faffing it is normal to escalate to admin and back again. There are a number of ways you can do this: using the secondary logon service (Runas/MakeMeAdmin), Terminal Services/Remote Desktop and Fast User Switching.

You’ve probably noticed that when you give yourself new privileges the changes don’t manifest themselves until the next logon. As the name implies, the secondary logon service (check it out in your list of services) enables you to start a process under alternate credentials using the runas command. It also pops up as the runas option in context menus and in the CreateProcessWithLogonW API.

At its simplest, you can do something like

runas /u:machinename\administrator cmd

and, after being prompted for a password, a command prompt will pop up running as admin (helpfully labeled as such on my XPSP2 box). Or you can get fancy with

runas /u:machinename\administrator "runas /netonly /u:domainname\username \"%comspec% /K""

I’ve had success with Keith Brown’s approach of having a red-coloured admin command prompt running with my domain credentials for network connections (see here for details). You can use it to launch Control Panel applets, run mmc, and install apps (see here for a list of applets and mmc files). This is a nice approach if you enjoy working in command windows.

I like an easy life so I tend to just set up some shortcuts for apps that need to run as admin with the runas flag on. Then when I double click on the shortcut I automatically get prompted to see whether I want to use alternate credentials. To enable this you just need to click the advanced button on a shortcut’s properties context menu and select “Run with different credentials”. By the way, the “Protect my computer and data from unauthorized program activity” option in XP runs the app with a restricted SID, somewhat similar to the C option on DropMyRights.

The disadvantages to the secondary logon approach are that malware can send Windows messages to the admin command prompt window (think Sendkeys). Also if you install an app that is so brain-dead that it takes user information at install time rather than at run time then you end up with your admin profile rather than your user profile.

Another thing to watch out for is programs that, once running, resist all attempts to launch additional instances of themselves. By default, if you try to run another instance of Explorer it laughs in your face and instead opens a new window from the existing process. Unfortunately, this prevents you from launching a separate instance of Explorer running as admin. This issue, with workarounds, is covered in more detail in Aaron’s Margosis’ blog here. The easiest thing to do is to launch IE instead although there are some refresh issues.

Aaron has evolved Keith Brown’s humble batch file to a minor art form in the shape of MakeMeAdmin. Rather than bring up a command prompt running as admin, MakeMeAdmin leaps through some hoops to add your user account to the administrators group and launch a command prompt using those credentials – before promptly removing you from the admins group again. You can read the details here and here.

The advantage of this approach is that the high privilege command window is running as you with administrator privileges. Brain-dead install programs pick up your profile correctly. Any objects you create will be marked either with your SID or the Administrators SID depending on the “Default Owner” setting which Aaron describes in detail here. Read this carefully to understand the ownership issues. The general disadvantage with MakeMeAdmin is again the possibility of a SendKeys attack.

The solution to this mixed desktop context issue is to either use a Remote Desktop to yourself (!) on Windows Server or to use Fast User Switching (FUS) on Windows XP. Both of these use Terminal Services technology to provide a separate desktop and you can switch between them as required.

Unfortunately, most developers’ main machine is not running W2K3 and you can only use Fast User Switching if you are not connected to a domain (there is also no offline folder support with FUS). This rules out a lot of us. Naturally, Windows Vista fixes this but in the meantime, FUS is incredibly useful for your home PC(s) where you can set up a separate admin account for games (which often need admin access) and low privilege accounts for browsing.

Using Visual Studio when logged as LUA

Versions of Visual Studio prior to VS 2005 can be painful to use as a non-admin – which is a shame seeing as most of the time you are just typing code. There is an MSDN article on how to work around all the issues. From a pragmatic point of view, if you can run as Visual Studio as LUA then fantastic but if you can’t then it’s still better to log in as a non-admin and set up a shortcut with VS running as admin than to log in as admin from the start.

This is probably as good a place as any to ask a question about privileges: is the cunningly named SeDebugPrivilege necessary in order to debug? The answer, perhaps surprisingly, is not in the majority of cases. By default, you can debug any process running as the currently logged in user. The time you need SeDebugPrivilege is when you have to debug a process running as another user. This normally happens when you want to debug a server process which, more often than not, is with an IIS web app.

So if you’re just hitting F5 in Visual Studio there shouldn’t be a problem. You will need to be in the “Debugger users” group for Visual Studio 2003 but this is a VS03 thing not a Windows thing. This group is created when VS is installed and allows access to the Visual Studio Machine Debug Manager component.

Note things are a bit different in Visual Studio 2005 – there is no Debugger users group (nor the VS Developers group for creating web sites) and the whole LUA experience is much, much better.

Well, when I’ve recovered from writing this post I’ll try another post talking about writing code that runs as least privilege. In fact, this is much more important than you personally logging in as admin. How you write your code can affect the experience and the security of many people and, what’s more, they are your customers. Be nice to them.

Some resources

1) Keith Brown’s .NET Developer’s Guide to Windows Security
2) Aaron Margosis’ blog
3) Peter Torr on non-admin
4) Larry Osterman on non-admin
5) Non-Admin Wiki
6) Least Privilege in Longhorn
7) How to develop code as a Non-Admin
8) The Challenge of Least Privilege
9) Browsing the Web and Reading E-mail Safely as an Administrator (Part 1)
10) Browsing the Web and Reading E-mail Safely as an Administrator (Part 2)
11) Developing Software in Visual Studio .NET with Non-Administrative Privileges
12) Using Software Restriction Policies to Protect Against Unauthorized Software

Least Privilege Questionnaire

2005-07-13T23:26:00Z

For how many of the following questions can you answer "no"?

1) Your PC is connected to the Internet
2) You have valuable things on your PC and it is probably joined to a corporate LAN
3) There are nasty people on the Internet who would like nothing more than to gain access to your PC and to your network
4) There are undiscovered vulnerabilities in the software running on your PC…
5) … that could be exploited by a hacker or by malware
7) Your anti-virus software is reactive and imperfect
8) You (sometimes) make mistakes: clicking yes when you mean no, downloading software you shouldn’t, opening email or IM you shouldn’t
9) There are webpages with “drive-by” installations of malware: you render a page in your browser and you're infected (and unaware of it)
10) You log on as an admin: a successful attacker or malware will have complete and utter control of your PC
11) You're a developer, you know about all of the above and you still log on as admin
12) Oh, and you have a weak password

64 bits should be plenty enough for anybody

2005-05-05T01:17:00Z

Bill Gates once remarked “640KB of memory should be plenty enough for anybody”. Actually, I have it on good authority that he didn't say it, but let's not let that get in the way of a good story. The reason the quote has stuck is that firstly, it was a pretty plausible thing to say at the time he (allegedly) said it and, of course, it's fun to see smart people getting predictions spectacularly wrong! The same thing happened to Thomas J Watson with his famous 1943 effort "I think there is a world market for maybe five computers". Or am I getting confused with the Professor in the time travel Simpsons episode...?

The common theme is a tendency to underestimate the power and ubiquity of computers in the future. Experience teaches us that we keep on requiring bigger and better hardware. Thank you Mr Moore! [An oracle if ever there was one.]

Recently I saw an email giving the number of x64 computers in use in Mircosoft in Redmond. I had no idea they were so abundant. I believe Gartner has been recommending 64-bit purchases for corporate customers, the local computer stores are full of 'em, and admittedly Microsoft is full of techies who like nothing better than to get their hands on some cool new hardware but even so, I was still taken aback.

64-bit has been on my back burner of things to look at but with the release of XP x64, it seems clear to me that 64-bit Windows is on the verge of becoming a mainstream, pervasive technology - on the desktop and the server. The time for me to get hold of an x64 machine and check out the 64-bit version of the .NET Framework has arrived. If you're an ISV then it's probably a good idea for you to do the same. Volker's blog is the one to watch for info on 64-bit Windows. It was there I learned that Intel have just started shipping their last 32-bit only processor!