Share via

Http.sys URL Registrations and Service SIDs

  • Article

 A common question we get when configuring HTTP.sys to listen on a URL (though HttpAddUrl, HttpAddUrltoUrlGroup, HttpListenerPrefixCollection or even CREATE ENDPOINT) is how you claim and protect your name space.

The first issue that people need to understand is the precedence rules for URLs. If you are really worried about having the whole namespace to yourself, then you may want to use the strong wildcard https://+:80/bar style URL so that your registration overrides hostname and IP address based reservations. A nice discussion of how this works is described on MSDN. On my laptop running a post Beta 2 build of Vista, 4 of the 7 reservations I have use the strong wildcard, including BITS and the Windows Media Player Network Service.

The next issue is understanding that HTTP.sys uses the Windows security model, which means that we use the process security token and compare it against the registered ACL that you probably set up during install time (while you had admin credentials). In an ideal world we would all have secure application Ids and just ACL the namespace resource to the application ID. On Windows XP and Windows 2003, the best level of isolation you get is the user account or groups your process is running under. If all users on the system needs to be able to run the application then you have to have wide open ACLs on the reservation, which means you have very little protection from any random application. The best you can do right now is to create your namespace with something that other people aren’t likely to step on. This is the same isolation model that applications writing to a user’s “Application Data” or even “Program Files” folders have today. If appropriate, you probably should use your company and/or app name as part of the URL namespace to help avoid collisions.

The same type of ACL problem exists for services, which often run under a couple of well known accounts, so in practice there isn’t much isolation except away from user processes. In Windows Vista things gets better because of a Service Hardening feature called Service SIDs. Since the service manager knows what service is running in any given process, it can maintain a list of per Service SIDs that show up when http.sys does its security checks. They built this functionality into windows security itself, so the Service SID concept works on anything that uses ACLs like files and registry keys. You can quickly recognize a Service SID because it starts with “S-1-5-80-“. Looking again at the default urlacl registrations on my laptop (“netsh http show urlacl”), I can see that two registrations are using Service SIDs in their namespace ACLS: BITS and Windows Media Player Network Service.

Service SIDs are generated automatically from the Service Name (this is the short name not the longer more friendly Display Name) in such a way that it is the same on every windows machine.  When I run “sc showsid BITS” (which is easier then calling LookupAccountSid), I get back the exact same Service SID that was in HTTP’s URLACL list. A really astute observer might notice that the output of netsh actually lists user names that you have never seen before:  NT SERVICE\BITS and NT SERVICE\WMPNetworkSvc. The Service SID alone isn’t reversible, but the system has another feature that caches the service SIDs and gives them friendly names for when you call the SID lookup API LookupAccountName. For an implementing service the only thing you need to call (with proper rights) is ChangeServiceConfig2 with SERVICE_CONFIG_SERVICE_SID_INFO structure set to SERVICE_SID_TYPE_UNRESTRICTED (or “Sc sidtype XXX unrestricted”) and an administrator could actually use the command line tools to alter the service and namespace URLACLs to lock down on vista a service that doesn’t know better.

Of course we still have to deal with the process as the security boundary which leads to an interesting “attack”. If a service MISBEHAVING is running in the same process as out ANGEL service, then the process will have the SIDS for both services and MISBEHAVING can register ANGEL’s URLs, but this only works while ANGEL is started and in the same process ANGEL’s service SID goes away when ANGEL stops. Of course the administrator had to have installed MISBEHAVING to begin with.

What is especially neat about this feature is that it wasn’t developed for HTTP.sys and we didn’t change any code to support it. It was free :). With Service SIDs I’ve had a glimpse at how an application id could work in Windows and I hope in some future release it gets added, finishing off this class of namespace security issues for good.

-- Ari Pernick (arip)