I think things that aren't part of the OS (media players, web browsers, instant messengers) should not ship with the default install.
I think Microsoft should be pretty much allowed to ship what they like with the retail box version of Windows. It's the OEM licenses that are the key, and ANY application should be permitted to be removed from the default lineup if the OEM desires.
That simple effect removes any ability for Microsoft to push their own apps on their monopoly platform and forces them to compete with other application retailers for OEM shippings.
Perhaps the real way to develop a vendor agnosticism would be to actively support and have people on the goverment payroll contribute to the open-source development model.
Hey, we could put Government funds into education and get the professionals there to develop open source software. I'll call up the Regents of the University of California, Berkley. Oh... Wait a minute...
In my opinion, if the government continues to fund software development then it should ensure it isn't under the GPL (BSD license springs to mind). After all, everyone who helped fund that software should have a right to it and not just those who also agree with the philosophy of GNU.
Hold on, I'm confused now:
- Only LocalSystem can impersonate another user.
- LocalSystem process needs to know the password of the user to impersonate
- But: LocalSystem can also set the password!
So what's the point of having a password in the first place?
The only reason is there is an underlying "philosophy" in the NT security architecture that to log in as a user you must either know the password or destroy the existing password (thus theoretically alerting the user). It should be noted that LocalSystem can only set the password for accounts with their security information located on the local machine (so you have to get LocalSecurity on a domain controller to tinker with domain user passwords).
The shame of it all is that LocalSystem has enough access power to read the hashes out of the registry/Active Directory, set the password, login and replace the hashes with the old ones while covering up the audit trail.
I would be far more enthusiastic about NT security if they created a new privilege (at least that much is obviously extensible) which allowed a user to effectively call setuid() with no password. The priv need not be given to anyone but LocalSystem by default and it would clean up a lot of the messy stuff you have to do to get around the obstacles in the design (which in turns opens the door for bugs and security problems).
I wonder if anyone from Microsoft is reading this?
[I'm assuming you weren't questioning the point of passwords in general, just the fact that LocalSystem needed them to login as another user]
Well, I would trust a packet router more if it had no web server code together with the routing code:-)
Yeah - having the whole web server in process is not so good, even if you strongly suspect (closed source) that it isn't being used.
Judging from the amount of damage Code Red & friends have done, I guess not too many people actually use it...
Nope - kills performance and isn't the default configuration. You honestly think the average NT "Admin" is going to know the difference between actual userid and effective userid?
To be honest, I'm not sure whether all ISAPI DLLs get run before the process/user switch or after - I'll write one and get back to you...
But in that case the password is irrelevant, so in effect it's just doing su.
Pretty much, just in a roundabout way.
In Unix you are guaranteed that no process (except root) will be able to su to that user.
In NT you are guaranteed that no process other than those that hold the "TCB" (act as part of the operating system) privilege are able to impersonate a user from a username/password pair. LocalSystem is the only account with this privilege and so the process must already have LocalSystem to get to the 'nobody' account. This is therefore not a security hole, even if the password was a fixed and unknown string.
In this case, Unix is actually more flexible than NT. You can allow a certain (non-root) user to switch to another user.
I agree. This is not possible on NT unless you either know the password of the target user or you don't mind actively setting the password.
In a way, I understand what they were thinking when the designed the system in this way (no user but LocalSystem can login as another user, always need a password, cannot give ownership of objects away), but in the end I think these added restrictions actually make the system less secure because of the careful holes you have to tear in the model to make things work. In summary, NT security is significantly more restrictive than Unix security which leads to people bashing holes in NT to make it workable - sometimes that hole is bigger than intended...
Was that coherent or should I try again to say what I mean?
But packets still go through the "primary" process which runs as LocalSystem, right? So what's the use of that?
Well, packets go through the kernel as well. The "use" of this is a packet router is far easier to make verifiably secure than a full web server. No matter which OS you are on, packets are going to touch superuser code somewhere, whether in the kernel or userspace. You just have to reduce the code to something *simple*, which a packet routing algorithm would definitely be.
Naturally, it would be nicer for the primary process to drop privs but not necessarily more secure.
That means the password must be hard-coded somewhere.
Nope. LocalSystem has the privilege to SET a user's password, so it makes up a huge string of random gunk and sets the password when IIS starts. Periodically it changes this by force setting the password again with a different string of random gunk.
[Disclaimer - the above description is from reading between the lines and isn't quite spelled out in as much detail, but makes sense. Damn closed source!]
I'm assuming that by that you mean ACL.
No. I mean privileges. With Unix (standard, not 'capabilities') it is an all or nothing model. Only (euid == 0) can do certain things. On NT there are a whole swag of privileges that you can specifically enable or disable. The privileges required to logon as a different user (ie call seteuid()) aren't held by any account other than LocalSystem.
Does IIS start 10 processes, each as a different user? Or does it actually mean that it will still run as LocalSystem and use "impersonation" to run *scripts* as different users, the way it already does?
This isn't quite true. IIS 5 can already be configured to run different virtual directories and sites as different users. It maintains the single listener running as LocalSystem, but farms each request to a separate process running as the specified user. You can easily verify this using the task manager to show which user owns which process - you'll see a few svchost.exe's running as the different web users.
In other words, IIS already has this option so I'm wondering exactly what they are going to add?
Ok, so setuid() does two things that are impossible on NT:
i) Irrevokably changes user (you can only ever set the effective user id on NT).
ii) Changes user WITHOUT needing a password (to change user on NT you always need to know the password, even if you are Admin/LocalSystem).
Note that as a result of (ii), it is impossible to switch to the LocalSystem user from a normal process - LocalSystem has no password (at least none I know of) and so the only way to create a process as this user it to convince another process that is already LocalSystem to create one for you. Of course, the easiest way to do this is 'at [time+1]/interactive cmd.exe'.
So which user does it run as again? How does a running process magically switch the user it runs as? Oh right it doesn't! IIS runs as LocalSystem. As AC pointed out, it uses "impersonation" to run *scripts* as another user (this is eqivalent to sudo). Repeat: it runs *scripts* as whatever user; IIS itself runs as LocalSystem.
Depending on how you configure it, it can have a secondary process spawned as a separate 'nobody' user that handles the requests. This lowers performance but (obviously) increases security. You can assign different users for different virtual directories.
Wait, all these special (service-only) accounts have passwords? So you can log in as say LocalSystem or IUSR_watever if you guess it?
Nope - they don't have permission for interactive or network login, only service login. Yes, they do have passwords (which IIS changes periodically). There is no such thing as an account on NT being allowed to switch user to another account unless it knows the password (ie 'su'/setuid() without passwords is impossible, even as LocalSystem), just as giving ownership of an object is impossible. And before you post another dumb response, here's a clue: on NT accounts have much finer grained permissions than on (standard) Unix - you would do well to look at them.;-P
The Resource Kit and Technet subscriptions aren't fixes (fixes are free), so your rant is unfounded. These items contain wads of documentation, best practices and other useful tools for a sysadmin and are well worth the money spent.
The real problem isn't that the service starts as LocalSystem - even Apache starts off as root (it has to when it binds to port 80). What makes things so difficult under NT is there is no effective way to permanently and irrevokably drop privileges from a process while maintaining the ability to 'su' to another user if someone presents a username/password pair.
Even when IIS is running as a 'nobody' user, unless you have explicitly configured your script/application to run in a separate process then you'll find that a simple 'RevertToSelf()' call will grant you back all the privs that were dropped. On the flip side, without being LocalSystem you can't call 'LogonUser()' or 'CreateProcessAsUser()' from a username/password pair so you end up with catch 22.
or, in terms of the old DOS days, exit(0). The fear comes in when you see it, know what it means and realize just how full your brain is of stuff you are never likely to use again...
I thought the same thing initially, but when I tried using CreatePipe() instead of CreateNamedPipe() I actually got a performance degradation of about 5%. Looking deeper into this, I found that CreatePipe() actually creates a named pipe and places security descriptors on each end which restrict it to unidirectional access (hence the slowdown).
From the MSDN documentation:
Windows NT/2000: Anonymous pipes are implemented using a named pipe with a unique name. Therefore, you can often pass a handle to an anonymous pipe to a function that requires a handle to a named pipe.
Okay, it's time to debunk the M$ admins are lazy myth a bit
Never said "lazy". I said stupid. Big difference.
... 8 clueless admins and 6 semi-knowledgable ones... If *ANY* of you suckers handle all that daily, and still have time to mess with patches on a regular basis... I did realize about three months before codered that we were a screaming hole for IIS exploits. Do I have time to cull through 30+ patches and tinker with which are appropriate to apply...
You have 14 other admins under you and you think it's YOUR job to test and apply patches? The real problem I see is you need to delegate some responsibility. There's no way you can do everything you are trying to do yourself so get one of those 14 to take over some of your tasks and report back to you. One thing about managers, they DO understand delegation (that's what they all do as well).
It's hard to do but at some stage you'll have to let go or you'll be doing 16 hour work days and drinking. Oh, wait...
Have fun admin'n your two Apache boxes.
What Apache boxes? We run IIS. I thought I said that somewhere?
There certainly is. I think it's just called 'Personal Web Services', but it is most definitely there. How else did you think you could run a web server and do all that FrontPage work on your local machine?
Correct me if I'm wrong, but I didn't think IIS (or Personal Web Services) was installed by default on Win2k Pro? This is all supposition because I can't remember whether I deliberately turned it on when I installed my machine or not (it's set to only accept on 127.0.0.1 though).
I thought a majority of web servers run a varient of linux
Here's the key to it. The majority of servers run some variant of Linux. Most buffer overflow bugs require a specific offset and known layouts in memory. If you look at the specific versions out there IIS is probably the most common single version of any product out there (can you get this info from Netcraft?)
On the other hand, it could just be stupid admins - check out http://www.netcraft.com/Survey/vuln.gif. I'm sorry, but those numbers make me puke when I think any of those people seriously call themselves admins...
Patch scenarios in Win9x have about as much relavance with IIS/NT patches as they do with Linux patches. They are different products, different teams and different focuses.
I wouldn't argue with anyone saying Win9x locks up, even if they weren't applying a patch at the time - it's fairly common knowledge what a complete mess the core is in.
Simply griping about Win9x problems and saying that NT is bad is just wrong though. May be the same company, but very different attitude to the two.
Perhaps if you bothered to read the parent to my original post you would have noticed it was a network admin whining about how much time it took him to keep 5 (yes, only five) Windows machines patched.
Of course, you are probably much happier flaming me than actually reading the context of my posts so, whatever...
I hope you spare some time in your rightoeus indignation to give Microsoft some kudos for making the critical updates part of XP. Oh, wait! You are probably going to flip to the other side of the fence and scream privacy issues?
Actually the patches for the flaws that Code Red and Nimda exploit were pretty well buried on Microsoft's site.
If you can call http://www.microsoft.com/security "buried". Personally I get the bullitens emailed to me - that way I don't have to surf over there. Had you done that you would have been patched three whole months before the worm came out.
Personally I trust script kiddies even less. If I see a published bug that allows root access from remote sites I close the damn thing straight away.
I remember SP6 very well. Downloaded the SP6a patch and had my eval boxes working before I deployed. There is NO excuse for waiting three months with an open root compromise though.
The proper action with CRed and Nimda isn't to rush to patch the server, but to change the firewall to prevent malicious requests.
No. By the time you've done this it is too late - the worm has already hit you. If you'd applied the patch (even taken a week, hell a month even, to evaluate it) then you wouldn't have to firewall things after the fact.
To do otherwise is to risk having to reinstall the OS (without the patch) to get your servers working again.
You don't reinstall after a root compromise? What sort of admin are you?
The risk of patching a single file or two with a hotfix (which saves backups anyhow for rollback) is significantly less than having your server root compromised.
the overhead on keeping the win machines patched (5 on the network) is crazy, I spend too much of my valuable time hunting down patches for machines
Install Windows Critical Update Notification.
If it honestly takes you too long to visit the Windows Update web site once every week for the 5 machines, or get the users to visit the site and install the critical updates then there's a problem somewhere.
My Win2k machines WERE running IIS and had all critical updates installed. No Code Red. No Nimda. WTF is everyone else's problem? Even my web host which is running IIS didn't get hit.
As for rewriting IIS, it is a rather stupid idea. First of all the Code Red problem wasn't IIS at all, but the Index Server ISAPI DLL. Rewriting IIS will have zero effect on any of these extensions, much as rewriting Apache would have little effect on a bug in mod_php.
Honestly I don't get Gartner's points here - if you have a significant site with a large investment in.asp pages and custom server ActiveX objects then migrating from IIS is a fairly large expense. Even if you don't, the hassle of securely setting up a whole new web server is just asking for more holes to turn up. I'd be recommending companies don't ship at all, but pay attention to Microsoft's security bullitens (you ARE signed up, aren't you?)
Slashdot Mirror
I think things that aren't part of the OS (media players, web browsers, instant messengers) should not ship with the default install.
I think Microsoft should be pretty much allowed to ship what they like with the retail box version of Windows. It's the OEM licenses that are the key, and ANY application should be permitted to be removed from the default lineup if the OEM desires.
That simple effect removes any ability for Microsoft to push their own apps on their monopoly platform and forces them to compete with other application retailers for OEM shippings.
Perhaps the real way to develop a vendor agnosticism would be to actively support and have people on the goverment payroll contribute to the open-source development model.
Hey, we could put Government funds into education and get the professionals there to develop open source software. I'll call up the Regents of the University of California, Berkley. Oh... Wait a minute...
In my opinion, if the government continues to fund software development then it should ensure it isn't under the GPL (BSD license springs to mind). After all, everyone who helped fund that software should have a right to it and not just those who also agree with the philosophy of GNU.
Hold on, I'm confused now:
- Only LocalSystem can impersonate another user.
- LocalSystem process needs to know the password of the user to impersonate
- But: LocalSystem can also set the password!
So what's the point of having a password in the first place?
The only reason is there is an underlying "philosophy" in the NT security architecture that to log in as a user you must either know the password or destroy the existing password (thus theoretically alerting the user). It should be noted that LocalSystem can only set the password for accounts with their security information located on the local machine (so you have to get LocalSecurity on a domain controller to tinker with domain user passwords).
The shame of it all is that LocalSystem has enough access power to read the hashes out of the registry/Active Directory, set the password, login and replace the hashes with the old ones while covering up the audit trail.
I would be far more enthusiastic about NT security if they created a new privilege (at least that much is obviously extensible) which allowed a user to effectively call setuid() with no password. The priv need not be given to anyone but LocalSystem by default and it would clean up a lot of the messy stuff you have to do to get around the obstacles in the design (which in turns opens the door for bugs and security problems).
I wonder if anyone from Microsoft is reading this?
[I'm assuming you weren't questioning the point of passwords in general, just the fact that LocalSystem needed them to login as another user]
Well, I would trust a packet router more if it had no web server code together with the routing code :-)
Yeah - having the whole web server in process is not so good, even if you strongly suspect (closed source) that it isn't being used.
Judging from the amount of damage Code Red & friends have done, I guess not too many people actually use it...
Nope - kills performance and isn't the default configuration. You honestly think the average NT "Admin" is going to know the difference between actual userid and effective userid?
To be honest, I'm not sure whether all ISAPI DLLs get run before the process/user switch or after - I'll write one and get back to you...
But in that case the password is irrelevant, so in effect it's just doing su.
Pretty much, just in a roundabout way.
In Unix you are guaranteed that no process (except root) will be able to su to that user.
In NT you are guaranteed that no process other than those that hold the "TCB" (act as part of the operating system) privilege are able to impersonate a user from a username/password pair. LocalSystem is the only account with this privilege and so the process must already have LocalSystem to get to the 'nobody' account. This is therefore not a security hole, even if the password was a fixed and unknown string.
like what [privileges]?
Look here for the complete list.
In this case, Unix is actually more flexible than NT. You can allow a certain (non-root) user to switch to another user.
I agree. This is not possible on NT unless you either know the password of the target user or you don't mind actively setting the password.
In a way, I understand what they were thinking when the designed the system in this way (no user but LocalSystem can login as another user, always need a password, cannot give ownership of objects away), but in the end I think these added restrictions actually make the system less secure because of the careful holes you have to tear in the model to make things work. In summary, NT security is significantly more restrictive than Unix security which leads to people bashing holes in NT to make it workable - sometimes that hole is bigger than intended...
Was that coherent or should I try again to say what I mean?
But packets still go through the "primary" process which runs as LocalSystem, right? So what's the use of that?
Well, packets go through the kernel as well. The "use" of this is a packet router is far easier to make verifiably secure than a full web server. No matter which OS you are on, packets are going to touch superuser code somewhere, whether in the kernel or userspace. You just have to reduce the code to something *simple*, which a packet routing algorithm would definitely be.
Naturally, it would be nicer for the primary process to drop privs but not necessarily more secure.
That means the password must be hard-coded somewhere.
Nope. LocalSystem has the privilege to SET a user's password, so it makes up a huge string of random gunk and sets the password when IIS starts. Periodically it changes this by force setting the password again with a different string of random gunk.
[Disclaimer - the above description is from reading between the lines and isn't quite spelled out in as much detail, but makes sense. Damn closed source!]
I'm assuming that by that you mean ACL.
No. I mean privileges. With Unix (standard, not 'capabilities') it is an all or nothing model. Only (euid == 0) can do certain things. On NT there are a whole swag of privileges that you can specifically enable or disable. The privileges required to logon as a different user (ie call seteuid()) aren't held by any account other than LocalSystem.
Does IIS start 10 processes, each as a different user? Or does it actually mean that it will still run as LocalSystem and use "impersonation" to run *scripts* as different users, the way it already does?
This isn't quite true. IIS 5 can already be configured to run different virtual directories and sites as different users. It maintains the single listener running as LocalSystem, but farms each request to a separate process running as the specified user. You can easily verify this using the task manager to show which user owns which process - you'll see a few svchost.exe's running as the different web users.
In other words, IIS already has this option so I'm wondering exactly what they are going to add?
Ok, so setuid() does two things that are impossible on NT:
/interactive cmd.exe'.
i) Irrevokably changes user (you can only ever set the effective user id on NT).
ii) Changes user WITHOUT needing a password (to change user on NT you always need to know the password, even if you are Admin/LocalSystem).
Note that as a result of (ii), it is impossible to switch to the LocalSystem user from a normal process - LocalSystem has no password (at least none I know of) and so the only way to create a process as this user it to convince another process that is already LocalSystem to create one for you. Of course, the easiest way to do this is 'at [time+1]
So which user does it run as again? How does a running process magically switch the user it runs as? Oh right it doesn't! IIS runs as LocalSystem. As AC pointed out, it uses "impersonation" to run *scripts* as another user (this is eqivalent to sudo). Repeat: it runs *scripts* as whatever user; IIS itself runs as LocalSystem.
;-P
Depending on how you configure it, it can have a secondary process spawned as a separate 'nobody' user that handles the requests. This lowers performance but (obviously) increases security. You can assign different users for different virtual directories.
Wait, all these special (service-only) accounts have passwords? So you can log in as say LocalSystem or IUSR_watever if you guess it?
Nope - they don't have permission for interactive or network login, only service login. Yes, they do have passwords (which IIS changes periodically). There is no such thing as an account on NT being allowed to switch user to another account unless it knows the password (ie 'su'/setuid() without passwords is impossible, even as LocalSystem), just as giving ownership of an object is impossible. And before you post another dumb response, here's a clue: on NT accounts have much finer grained permissions than on (standard) Unix - you would do well to look at them.
The Resource Kit and Technet subscriptions aren't fixes (fixes are free), so your rant is unfounded. These items contain wads of documentation, best practices and other useful tools for a sysadmin and are well worth the money spent.
The real problem isn't that the service starts as LocalSystem - even Apache starts off as root (it has to when it binds to port 80). What makes things so difficult under NT is there is no effective way to permanently and irrevokably drop privileges from a process while maintaining the ability to 'su' to another user if someone presents a username/password pair.
Even when IIS is running as a 'nobody' user, unless you have explicitly configured your script/application to run in a separate process then you'll find that a simple 'RevertToSelf()' call will grant you back all the privs that were dropped. On the flip side, without being LocalSystem you can't call 'LogonUser()' or 'CreateProcessAsUser()' from a username/password pair so you end up with catch 22.
If I'm wrong, please shoot me down in flames...
It's x86 machine code for:
MOV AX,4C00 (note little endian)
INT 21
or, in terms of the old DOS days, exit(0). The fear comes in when you see it, know what it means and realize just how full your brain is of stuff you are never likely to use again...
I thought the same thing initially, but when I tried using CreatePipe() instead of CreateNamedPipe() I actually got a performance degradation of about 5%. Looking deeper into this, I found that CreatePipe() actually creates a named pipe and places security descriptors on each end which restrict it to unidirectional access (hence the slowdown).
From the MSDN documentation:
Windows NT/2000: Anonymous pipes are implemented using a named pipe with a unique name. Therefore, you can often pass a handle to an anonymous pipe to a function that requires a handle to a named pipe.
Okay, it's time to debunk the M$ admins are lazy myth a bit
... 8 clueless admins and 6 semi-knowledgable ones ... If *ANY* of you suckers handle all that daily, and still have time to mess with patches on a regular basis ... I did realize about three months before codered that we were a screaming hole for IIS exploits. Do I have time to cull through 30+ patches and tinker with which are appropriate to apply ...
Never said "lazy". I said stupid. Big difference.
You have 14 other admins under you and you think it's YOUR job to test and apply patches? The real problem I see is you need to delegate some responsibility. There's no way you can do everything you are trying to do yourself so get one of those 14 to take over some of your tasks and report back to you. One thing about managers, they DO understand delegation (that's what they all do as well).
It's hard to do but at some stage you'll have to let go or you'll be doing 16 hour work days and drinking. Oh, wait...
Have fun admin'n your two Apache boxes.
What Apache boxes? We run IIS. I thought I said that somewhere?
there is no IIS in Windows 2000 Professional
There certainly is. I think it's just called 'Personal Web Services', but it is most definitely there. How else did you think you could run a web server and do all that FrontPage work on your local machine?
Correct me if I'm wrong, but I didn't think IIS (or Personal Web Services) was installed by default on Win2k Pro? This is all supposition because I can't remember whether I deliberately turned it on when I installed my machine or not (it's set to only accept on 127.0.0.1 though).
I thought a majority of web servers run a varient of linux
Here's the key to it. The majority of servers run some variant of Linux. Most buffer overflow bugs require a specific offset and known layouts in memory. If you look at the specific versions out there IIS is probably the most common single version of any product out there (can you get this info from Netcraft?)
On the other hand, it could just be stupid admins - check out http://www.netcraft.com/Survey/vuln.gif. I'm sorry, but those numbers make me puke when I think any of those people seriously call themselves admins...
Patch scenarios in Win9x have about as much relavance with IIS/NT patches as they do with Linux patches. They are different products, different teams and different focuses.
I wouldn't argue with anyone saying Win9x locks up, even if they weren't applying a patch at the time - it's fairly common knowledge what a complete mess the core is in.
Simply griping about Win9x problems and saying that NT is bad is just wrong though. May be the same company, but very different attitude to the two.
Perhaps if you bothered to read the parent to my original post you would have noticed it was a network admin whining about how much time it took him to keep 5 (yes, only five) Windows machines patched.
Of course, you are probably much happier flaming me than actually reading the context of my posts so, whatever...
I hope you spare some time in your rightoeus indignation to give Microsoft some kudos for making the critical updates part of XP. Oh, wait! You are probably going to flip to the other side of the fence and scream privacy issues?
Actually the patches for the flaws that Code Red and Nimda exploit were pretty well buried on Microsoft's site.
If you can call http://www.microsoft.com/security "buried". Personally I get the bullitens emailed to me - that way I don't have to surf over there. Had you done that you would have been patched three whole months before the worm came out.
The problem is that you can't trust MS's patches.
Personally I trust script kiddies even less. If I see a published bug that allows root access from remote sites I close the damn thing straight away.
I remember SP6 very well. Downloaded the SP6a patch and had my eval boxes working before I deployed. There is NO excuse for waiting three months with an open root compromise though.
The proper action with CRed and Nimda isn't to rush to patch the server, but to change the firewall to prevent malicious requests.
No. By the time you've done this it is too late - the worm has already hit you. If you'd applied the patch (even taken a week, hell a month even, to evaluate it) then you wouldn't have to firewall things after the fact.
To do otherwise is to risk having to reinstall the OS (without the patch) to get your servers working again.
You don't reinstall after a root compromise? What sort of admin are you?
The risk of patching a single file or two with a hotfix (which saves backups anyhow for rollback) is significantly less than having your server root compromised.
Index Server is not part of IIS. You install and uninstall it independantly and it runs as a separate service with isapi hooks into IIS.
If you are a competent admin, I'd expect you to be on the mailing lists for security flaws in all systems you administer - if not then you aren't doing your job properly. There's no excuse for not having a patch for "Unchecked Buffer in Index Server ISAPI Extension Could Enable Web Server Compromise" installed on a web server.
You don't need the browser on the server. You need some of the HTML related libraries on there that only get shipped with the browser.
Your question should really be "Why doesn't Microsoft ship a libhtml.rpm type of package instead of making us install IE(n+1)?".
The browser is no more "built-in" to the system than Konquerer is built into Linux (it's a user mode HTML renderer that the default GUI shell uses).
the overhead on keeping the win machines patched (5 on the network) is crazy, I spend too much of my valuable time hunting down patches for machines
.asp pages and custom server ActiveX objects then migrating from IIS is a fairly large expense. Even if you don't, the hassle of securely setting up a whole new web server is just asking for more holes to turn up. I'd be recommending companies don't ship at all, but pay attention to Microsoft's security bullitens (you ARE signed up, aren't you?)
Install Windows Critical Update Notification.
If it honestly takes you too long to visit the Windows Update web site once every week for the 5 machines, or get the users to visit the site and install the critical updates then there's a problem somewhere.
My Win2k machines WERE running IIS and had all critical updates installed. No Code Red. No Nimda. WTF is everyone else's problem? Even my web host which is running IIS didn't get hit.
As for rewriting IIS, it is a rather stupid idea. First of all the Code Red problem wasn't IIS at all, but the Index Server ISAPI DLL. Rewriting IIS will have zero effect on any of these extensions, much as rewriting Apache would have little effect on a bug in mod_php.
Honestly I don't get Gartner's points here - if you have a significant site with a large investment in
The problem is that non-privileged users have access to raw sockets.
Wrong. Write some test code, or look at the test code from my previous post. You try to use raw sockets as a non-admin user in XP and you get EACCESS.
Gibson is telling you lies.
Having to close all program and log off just to make small changes requiring Admin access has pissed me off more than once.
You never just used the 'Run As...' option in Win2k? Man, I can see why you would be upset.