![[SJF Logo]](../images/sjflogo.gif)
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:
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"
the white paper: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.
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.
Very early, the Windows Firweall "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
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
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.
This "safety-net" can be illustrated similarly in a UNIX context.
An application is "broken" if the safety-net SD blocks a request that the application would have accepted.
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:
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.int kernel_chmod(kernelfile *kfile, mode_t mode) { if (! kfile->is_temporary ) mode &= ~0x02; // turn off "write other" // perform the chmod operation }
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
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]
These calls provide:
One minor area of concern:
the Changes document"Should" ?
Applications should get user consent before adding themselves to the AuthorizedApplications collection.
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
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:
"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.
Pentium page table entries - no "execute" granularity
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'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-ckecking.
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"
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.
Task Scheduler security context
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 white paper:... and the screenshot of these boxes shows Norton Antivirus.
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]
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
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
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
IE: MIME type checking
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
Nav: More Tech Tips
Tools
My weblog
