Does this site look plain?

This site uses advanced css techniques

NOTE - This was written in the spring of 2004 when XP Service Pack 2 was in beta, but as far as we know, all of this applies to the software as released in August 2004.

Microsoft is now in beta on XP Service Pack 2, and it contains a lot of changes with an eye for security. There is a lot of discussion about these matters, but I've not seen a detailed third-party analysis of it (though I'm sure some have been made).

I'm basing my analysis only on documents provided by Microsoft and not on actually running the code: I have not seen or installed XP/SP2 yet nor read anything non-public about it (though I'm researching this now). In particular, this analysis predates the XP/SP2 Release Candidate 1 posted on Microsoft's website in late March 2004.

These documents were my main references:

Executive Summary

These appear to me to be outstanding efforts - by far the biggest real security push I've seen Microsoft actually make (as compared to "just talking about it"). I would characterize these changes as pervasive and comprehensive, and they appear to have no ulterior motive beyond "let's make security better".

When Microsoft is willing to break existing applications in the name of security, it suggests they really mean it.

Some of them are very simple - they now disable the Messenger Service by default - but some are changes down to the core of the operating system. The changes to the RPC permissions system, in particular, are very deep, and this must have been a nightmare to coordinate and test. I'd be surprised if they didn't find bugs in their own applications when tightening up the RPC permissions.

In addition, I have not seen anything that could possibly be construed as "anti-competitive" unless you consider that the new Windows Firewall will give the ZoneAlarm cohort a run for their money (perhaps literally). I have seen nothing about "Trusted Computing", nor anything new about Digital Rights Management. It's possible that these elements are in SP2, but it's not apparent. I hope others find them if they're present.

I am very, very impressed, and I actually have some hope that I'll be able to really secure the desktop of my customers. Anybody who says that this is a do-nothing Service Pack either hasn't studied it or is incorrigibly in the "Microsoft sucks" camp.

New "Windows Firewall"
There is a new Windows Firewall that's a substantially improved version of Internet Connection Firewall (ICF).
the white paper:
The firewall turns on very early in the system boot cycle, before the network stack is fully enabled, reducing the possibility of intrusion during the boot cycle. It also turns off very late in the shutdown cycle, after the network stack has been disabled.
This firewall can participate in "Group Policies", which allow for centralized management throughout an enterprise via the domain controller ("Active Directory" stuff). It would probably be welcome by the administrators of (say) a high school to lock down all the machines in the library so students could not bypass it.
Very early, the Windows Firewall "boot-time policy" allows only a few bits of traffic: DHCP, DNS, and communicating with the domain controller to fetch Group Policy. This boot-time policy cannot be configured (perhaps to prevent users from bypassing those Group Policies).
Once running, the Windows Firewall policies kick in, and there is a GUI to manage it. It appears to look like "a regular firewall" familiar to many users. The GUI appears to be user friendly, though I don't know yet if they characterize unknown inbound traffic as "attacks". I hope not.
It doesn't appear that Windows Firewall supports egress filtering, which prevents software from making an outbound connection. This is useful for catching badware trying to "phone home". The commercial personal firewalls (such as Zone Alarm) will still have an edge here if this is the case.
Local subnet restriction
The Windows Firewall also has a mechanism to restrict inbound traffic (on a per-port basis) only if that connection is coming from the local subnet. These restrictions apply by default to filesharing and UPnP ports, and they have the effect of allowing a small local network (the green zone) to "just work correctly" while blocking this dangerous traffic from the outside world ("the red zone"):
[local subnet diagram]
This is something I've talked about before, and it's a fantastic idea. This alone will block the great majority of bad things, because there's simply no way to talk to these juicy and powerful ports even on an out-of-the-box machine attached to the internet.
These rules may have somewhat less effect for cable modem users where the DHCP-provided IP address and netmask treats all users on the same cable node as "local". This remains to be seen.
These are all implemented by firewall rules, and can be reconfigured by the user.
DCOM/RPC Security Enhancements
Lots of changes to Remote Procedure Call system, and the description in the white paper seems to hit the nail right on the head:
the white paper:
Windows XP systems as normally installed have over 60 RPC-based services running that listen for client requests on the network, mostly in processes called Svchost.exe. If unprotected, these present a huge "attack surface" for intruders. In previous versions of Windows, ICF blocked all RPC communications from outside the computer, which interfered with file and print sharing and remote administration as well as other useful services. This is one reason why many users did not run ICF. [emphasis mine]
A new system policy restricts RPC services to local and/or authenticated clients only: this means that the "Messenger Spam" would not work any longer, because those connections are neither local nor authenticated. This change is at the system level, not in the individual RPC services.
I believe this is the change most likely to break existing applications, and it's generated a lot of negative heat that attributes a non-technical motive to Microsoft. I believe that heat is entirely misdirected. With the caveat that I am not an RPC programmer, I believe I can explain what they're doing.
The Win32 Security API provides very fine-grained control over access to most system resources: files, shares, mutexes, window stations, registry keys, and the like. It provides much more control than any UNIX security API does, and this power makes it non-trivial to use correctly.
"RPC Endpoints" get these security descriptors too, and it seems that many programmers with a lack of skill and/or clue have punted on the whole issue by creating a security descriptor with a NULL DACL (Discretionary Access Control List). These have the effect of allowing unfettered access to the resource.
There are perfectly legitimate reasons for doing this for some kinds of securable objects, but not for RPC endpoints. The programmer who didn't want to think about proper DACL construction has written an insecure application, and XP/SP2 will no longer allow this.
I'm speculating on how it's implemented, but my guess is that during the connect-to-endpoint call, the kernel applies a "bare minimum" security descriptor before consulting the SD provided by the RPC server via CoInitializeSecurity(). This "safety-net" SD enforces things like "you must be an authenticated user unless you're local", and "only administrators can do that". Only after passing this test are the server-provided DACLs considered.

Securely-written software already includes these tests, and those applications won't be affected by the change. Yes, the safety-net SD will block some requests, but only those that would have been denied by the application anyway.

An application is "broken" if the safety-net SD blocks a request that the application would have accepted.

This "safety-net" can be illustrated similarly in a UNIX context.
When writing a multi-user application in UNIX, it may require that these users have shared access to some common data folder, say, /usr/local/unixwiz/. There are several ways to grant secure access to these files: put them all in a particular group shared by all the users, or make a setuid/setgid front end that gives access to the files.

These techniques are all well known, but some developers take a lazy approach: chmod 777 /usr/local/unixwiz/*. Now all files are open to all users for anything, and this is terribly insecure, but it "works", and the downside is not really apparent.

What Microsoft has effectively done is said that "chmod 777" is no longer allowed: you cannot set the "write by others" bit outside of circumstances that do not apply here (just for discussion, let's say that you can only do chmod 777 on files in the /tmp directory).

A change to the kernel could be made to look like: 

int kernel_chmod(kernelfile *kfile, mode_t mode)
{
    if (! kfile->is_temporary )
        mode &= ~0x02;             // turn off "write other"

    // perform the chmod operation
}
Your request for an insecure mode is overridden: the "bar is raised" to forbid this, so you are simply forced to deal with the security in the right way.

I believe that the global safety-net DACLs are configurable to some degree, and there are methods that an RPC server can use to enable "the old way" if this is truly warranted. The impression I got is that the "workaround" (writing an authentication callback?) is much more work than fixing the DACLs correctly in the first place.

The bigger-picture point here is that "breaking existing applications" has nothing to do with nonsense such as "you now have to use Passport" or "you have to have your application certified in order to use RPC". They are simply making non-optional what should have been done all along.

"On with no exceptions" firewall mode
Routine management of the firewall will often mean relaxing of the rules somewhat: allow filesharing applications, allow an instant-messenger to receive files or direct connections from other users, or the like.
But Windows Firewall has a "Turn on the firewall and turn off all the exceptions" mode, that permits no inbound connections of any kind. This allows for looking into potential virus/Trojan infections without having to reconfigure the firewall. Outbound connections are still allowed in this mode, just not inbound.
Firewall API calls - [programmers only]
There is what appears to be a new API for talking to the firewall, and an application can call INetFwOpenPort() to add or disable access to the firewall. I've not seen any actual API specifications for this yet, so it seems pretty clear that this is new in XP/SP2.

These calls provide:

  • name of the executable to be granted access
  • "Friendly name" for the program
  • "Local subnet only" flag
  • Enabled/disabled flag
Applications are requested (by the documentation) to ask the user first if the firewall rules should be added or not, and if the user says "no", the rules should nevertheless be added with a "disabled" flag (which does not allow the traffic): this presumably makes it easier for the user to later enable the application because the rules and "friendly name" are already in place. Only processes with Administrator privileges are allowed to do any of this.

One minor area of concern:

the Changes document
Applications should get user consent before adding themselves to the AuthorizedApplications collection.
"Should" ?

A rogue application running as Administrator could easily add itself to the list with a "friendly name" of Internet Explorer or the like and fool the user.

This could only happen if the user ran some badware, and I'm not sure if there is any way to get around this beyond simply forcing some kind of GUI dialog box entry for every update to the Firewall API.

When in "On with No Exceptions" mode, these API calls are processed, but they don't actually take effect until the mode is exited.

Disable execute on data-only pages
When the processor supports it, they will disable "execute" permissions on "data only" pages, which will make an awful lot of buffer overflows not work. This is not a complete fix, and not many processors have this feature yet (apparently), but it's going to turn a very bad "remote-execution" vulnerability into just an annoying "application crash"

All modern processors have some level of page protection, but not at the level required to achieve this. The Pentium II, for instance, can mark a page as read/write or read-only:

[Pentium page table]
Pentium page table entries - no "execute" granularity
"Execute" permission is apparently considered a "read". The Itanium processors have more granularity than this, and will be able to disable execute on a read page. I believe that there are techniques for accomplishing some of this on pre-Itanium, but I believe they are hard to get right and have serious performance impacts.

This will impact applications such as Just-In-Time compilers (as used by Java), because they store executable code in data pages, and it may be some amount of work to re-architect their applications to allow this.

All memory provided from HeapAlloc() is no-execute, but that from VirtualAlloc() can have the execute bit set (among others). Code that executed out of Heap memory was probably never technically correct, though I don't think it's been spelled out. Whether this is "hard" or "easy" to fix remains to be seen - I guess we'll have to ask Sun.

Older applications may be harder to retrofit, but my guess is that XP is not commonly run on the processors that support this mode. Instead, these high-end processors are more likely to run one of the Server operating systems, so this whole problem won't come to a head for most users for some time.

Heap "Sandboxing"
They have implemented what they call "sandboxing", though I believe they are stretching the term from its customary use of a highly protected runtime environment.

They've rebuild the system binaries to enable stack buffer-security checks in the compiler. This usually involves placing a "cookie" (which has nothing to do with a "web" cookie) just after memory buffers. Normal array operations on these buffers won't disturb the cookies, but a buffer overflow will modify this cookie.

It won't prevent the overflow, but it will detect it - I believe that early detection is sufficient to mitigate many heap overflows. There is similar code added to the stack-checking.

I suspect this will have a tiny negative impact on performance, but it's probably too small to measure.

Annoying (in a good way) "Security Center"
Users who are insecure will have a much harder time claiming that they had no idea, because the new "Security Center" seems to make these security issues much more visible:
the white paper:
Users will also find that Security Center nags them a bit if they lack an antivirus program, if the antivirus signatures are out of date, if they ignore critical system updates, or if they turn off their firewall

There are provisions for advanced users to turn this all off, but my first impression is that it will only be of limited benefit. A few users will catch a clue from it, but most will just glaze over and click through yet another dialog box asking to do something bad.

[I-AM-A-VIRUS.EXE]
Task Scheduler security context
The Task Scheduler will require that all tasks run as a specific user rather than in the default security context (LOCAL\SYSTEM ?), so it will require entering a username and password in the setup for the task.

For users who are Administrators, this won't help much, but I believe that the "move to non-admin users" is going to continue as software developers get more experience doing so, so this is a great start down that road.

I suspect that changing a user password will require revising the task-setups that run in those contexts. I'm sure Microsoft has found a safe and secure way to store those passwords.

Attachment Execution Service
The new AES acts as a kind of vetting service for downloadable content, and it's consulted by Outlook Express, Windows Messenger, and by Internet Explorer. It's much smarter than just "looking at the file extension" when deciding whether an attachment is safe or not.
the white paper:
If the attachment is clearly unsafe, like a binary executable, it will be blocked: the user will not be able to open it at all, but will see a notice of blockage. If the attachment might be safe and might be dangerous, the user will see a warning prompt when attempting to drag, save, open, or print the file. If the user accepts the option, the file will be handled in a way that is guaranteed to trigger any active antivirus program. [emphasis mine]
... and the screenshot of these boxes shows Norton Antivirus.

There is similar behavior for Windows Messenger, and since AES is implemented as a COM object, I don't see any reason why Yahoo! or AOL IM couldn't get in on the fun too.

This looks really well done, and it's the one API I'm most interested in seeing.

Restricted "preview" in Outlook Express
Outlook Express has additional new behavior to suppress any HTML rendering or image fetching while previewing a message. This means that you'll be able to at least look at a message without triggering a virus or fetching a spammer's web bug. If the message appears safe (it really is from Mom), one button will fully fetch and preview the content.

It also will permanently disallow "binary behaviors", which use a specialized kind of COM interface used by IE. They say these are dangerous and should not be used, but I have no knowledge of any implications of this change.

IE: Managing Add-ons
Almost everybody who uses Internet Explorer has approved an "add-on", which is usually an ActiveX control or a Browser Help Object (BHO). These Add-Ons range from the Windows Update control (used by nearly everybody), to the friendly Google Toolbar, to the not-so-friendly Gator spyware yes, I called it "spyware".

Currently, there is no easy way to see what's been installed, but SP2 introduces a "Manage Add-Ons" GUI tool. You can see everything that's been installed and disable one at a time.

This will be a Godsend for administrators trying to figure out why somebody's computer is wigging out: "Oh, the idiot downloaded the XXXXX control. I'll disable it".

I didn't see provisions for putting this under Group Policy, but I suspect that the whole "Internet Zone" thing already is.

IE: Better Zone Management
Lots of changes about "zone management", and they seem to be quite comprehensive and thoughtful. They now have a new "Local Machine" zone that applies to things that are on the local hard drive. Previously, "local" content was considered secure, so if something got to the hard drive via other means, it could be exploited if requested from the browser. This "Local Machine" zone addresses this directly.
IE: MIME type checking
Internet Explorer SP2 now requires that all file-type information provided by webservers be consistent, and I suspect this will break a lot of web content that provides incorrect MIME types. If the Content-Type of a file is said to be text/plain but the "MIME sniff" (Microsoft's words!) indicates it's an executable file, it will rename the file in the IE cache and give it a better extension.

This shows a clear clash between "functionality" and "security": in the past, if the Content-Type said one thing but the file's content suggested another, the browser was being helpful by acting on the "real" content (e.g., if a GIF file was sent up with type "text", it would still display it as GIF). What was once a feature is now a bug: they've fixed it.

IE will also use the Attachment Execution Service.

IE also has a new Pop-Up Manager.

"Alerter" and "Messenger Services" Disabled
These are part of the WinPopup system, and it's the mechanism that "Messenger Spam" uses. They can be easily enabled in the "Services" control-panel applet.

Last updated Fri Mar 19 22:46:22 PST 2004