So what exactly is your problem with WSH (or Outlook, for that matter)? Yes, if the user goes out of his way to enable.vbs attachments in Outlook, and then is stupid enough to execute them, he's screwed. Same as with.exe or any other executable type. Which is exactly why these types are blocked by default.
Actually, for Windows XP Home Edition or XP Professional not part of a domain, it is still true.
Which wizard are we talking about? The one under Control Panel | User Accounts most definitely does not add limited accounts to Power Users, part of domain or not.
in Windows 2000 (and I believe this is still the case in XP in XP) if you just follow their guidance and use the Wizard interface to create a "Normal User", that user will be a member of the "Power Users" group.
This is definitely not true in XP, and I doubt it was true on Win2K.
On XP the wizard gives you 2 choices: computer administrator and limited. Limited accounts are not members of Power Users.
In practice, any user that's not in a kind of kiosk mode needs to be a member of the local "Power Users" group to function normally.
My account is not a member of Power Users and I'm still able to "function normally". The only thing that I had changed in the default configuration was give myself the "change system time" privilege so that the "Date and Time Properties" control panel applet works.
I was able to break into LOCALSYSTEM from Power User within five minutes of sitting down at a Windows NT box for the first time in my life
This is from the description of the "Power Users" group in the user manager (on XP SP2):
Power Users possess most administrative powers with some restrictions.
It's never been claimed that Power Users can't elevate to System. The only reason why Power Users exists is for situations like when some stupid program refuses to run without admin rights. It provides some protection against accidental damage but is not intended to stop a determined attacker.
Now if you can do the same from a *regular* user account it would be much more interesting. Bugs that allow a regular user to elevate himself to System are considered exploits and are fixed, just as on Linux.
RPC is not the problem, the problem is that too many network services are enabled by default.
Well, then just disable that pesky RPC service on your workstation and then write back and let us know how that works.
How is that related to what I've said? Let me repeat it again: RPC simply provides functionality that other services need. If there was no RPC then those other services would have to implement this functionality themselves, instead of relying on a single well tested implementation.
The problem therefore is not with RPC, it's with those other services like DCOM, WMI etc. that are enabled by default and rely on RPC. If you are sure that you don't need any of these services, you can block RPC traffic using built in firewall or ipsec.
But if you want to be able to use some of these services (let's say WMI) then stop bitching about having to open RPC ports because if WMI implemented its own authentication layer it would have been less secure, not more.
But the problem is (if you read the article...) that there are far more processes in Windows that run with privilege than those that are restricted.
I wasn't replying to the article. I replied to the person who said "all of the Windows exploits can reliably execute arbitrary system code" which is false.
RPCs are potential security risks...
RPC is not the problem, the problem is that too many network services are enabled by default.
But if each service implemented its own authentication mechanism instead of relying on RPC, things would have been even worse.
because of how Windows deals with security tokens (here [wiley.com] is a good place to start if you're curious), any exploit that gains access can probably execute code in the SYSTEM context
What's so special about the way Windows handles "security tokens"? If the exploit is in a component that runs as a limited user, you'll need an additional local root exploit to get System rights - same as in any other OS.
So, of the Linux exploits that are trivially available to exploit, none can reliably execute arbitrary system code, while all of the Windows exploits can.
It seems quite plausible to me that every request to render a page might kill any previous thread readering for the window, and start a new one, and this could quite successfully hide rendering engine failures.
I'm pretty sure IE doesn't do this. The reasonable thing to do is to let the application crash so that users can submit a crash report, and the problem can be fixed. Trying to continue execution after unhandled exceptions usually leads to undebuggable hangs.
I guess I really have no idea how one would authoritatively detect if the IE rendering engine has failed. Does anyone?
Terminal Services is great if you just want to log into a computer, but if you want to interact with another user or your own session already in progress [...] Terminal services will cause you to be logged in twice on the same machine, causes all sort of strangeness.
On W2K3 mstsc can connect to the console session (mstsc/console).
Software-enforced DEP performs additional checks on exception handling mechanisms in Windows. If the program's image files are built with Safe Structured Exception Handling (SafeSEH), software-enforced DEP ensures that before an exception is dispatched, the exception handler is registered in the function table located within the image file.
It does some checks but only before an exception is dispatched, and only for binaries built with/SAFESEH switch.
This behavior change can make it seem to Joe User like the power glitched...
After a power glitch you don't get the "Windows has recovered from a serious error... Do you want to submit error report to Microsoft?" dialog on the next boot.
...a hardware fault caused an NMI, etc, instead of Windows just flaking out for some random reason.
BSODs can and do often happen as a result of hardware faults. The only way to find out if it's caused by hardware or Windows "flaking out" is to analyze the crash dump with a kernel debugger.
An attacker who successfully exploited this vulnerability could gain the same privileges as the user. Users whose accounts are configured to have fewer privileges on the system would be at less risk than users who operate with administrative privileges.
Hey, at least we can do that. MS apps don't conform well to the Principle of Least Privledge.
IE runs just fine as a limited user.
In fact, when it comes to respecting the principle of the least privilege, IE is better than most Windows apps because it can even work with a restricted token (right-click IE shortcut, Run As..., Check the "Protect my computer" option).
Lessee: 200 incompatible applications, some of them Microsoft's own
And most of them can be made "compatible" simply by configuring an exception in the firewall. What's the big deal?
a hotfix released before the SP has even reached the masses
OK, so that's one legitimate (but low impact) bug discovered so far. Given the huge number of changes to the OS I'd say this is not that bad.
a much-hyped firewall that doesn't check outgoing connections (but pops up misleading dialogs that confuse the user into thinking it does)
The dialog says: "Windows Firewall has blocked this program from accepting connections from the Internet or a network". What's misleading here?
Not to mention the fact outgoing connection blocking can be trivially bypassed by malware. Implying that a software firewall can reliably prevent malware from calling home is what I'd call misleading.
quite a few people complaining about much strangeness after installing it
How many is "quite a few"? How many of these problems are because of bugs in SP2 as opposed to bugs in 3rd party software?
Personally, I haven't had any problems on my two XP machines.
I was under the impression that you had to enable multiple desktops, and install the debugger. I know 'windbg' doesn't run on my pc
Ntsd is already installed on all NT based systems, and can even be run without showing any UI.
That's not the point though - it all comes down to the fact that if you run a piece of native code then this code has the same privileges as you do. You have full control over what your processes are doing (you can debug your processes, you can inject arbitrary code into them, hide or change any part of their UI etc). So the malware can do all of this as well.
then any and all of those methods should be considered critical security flaws
Well, that's how native code works - any executable you run has the same rights as you do. Unless you restrict yourself to only running managed code (like.NET or Java) there's nothing you can do about it.
While their new XP SP2 firewall is somewhat degraded comared to, say, ZoneAlarm, thats not entirely a bad thing.
It's a GOOD thing. Outgoing connection blocking can easily be bypassed by worms or malware, it adds complexity to the firewall and trains users to click 'yes' on any security related message boxes. Leaving it out was the right thing to do.
I don't disagree with the statement that the message WILL get out... however, I WILL know about it.
Unless, of course, I hide the window, or create it on an inactive desktop, or start the user's default browser under debugger and inject my evil code into it before it even displays the window.
Trying to prevent code that runs with the same privileges as the user from making outgoing connections is a waste of time.
Slashdot Mirror
So what exactly is your problem with WSH (or Outlook, for that matter)? Yes, if the user goes out of his way to enable .vbs attachments in Outlook, and then is stupid enough to execute them, he's screwed. Same as with .exe or any other executable type. Which is exactly why these types are blocked by default.
Which wizard are we talking about? The one under Control Panel | User Accounts most definitely does not add limited accounts to Power Users, part of domain or not.
This is definitely not true in XP, and I doubt it was true on Win2K.
On XP the wizard gives you 2 choices: computer administrator and limited. Limited accounts are not members of Power Users.
In practice, any user that's not in a kind of kiosk mode needs to be a member of the local "Power Users" group to function normally.
My account is not a member of Power Users and I'm still able to "function normally". The only thing that I had changed in the default configuration was give myself the "change system time" privilege so that the "Date and Time Properties" control panel applet works.
This is from the description of the "Power Users" group in the user manager (on XP SP2):
Power Users possess most administrative powers with some restrictions.
It's never been claimed that Power Users can't elevate to System. The only reason why Power Users exists is for situations like when some stupid program refuses to run without admin rights. It provides some protection against accidental damage but is not intended to stop a determined attacker.
Now if you can do the same from a *regular* user account it would be much more interesting. Bugs that allow a regular user to elevate himself to System are considered exploits and are fixed, just as on Linux.
Well, then just disable that pesky RPC service on your workstation and then write back and let us know how that works.
How is that related to what I've said? Let me repeat it again: RPC simply provides functionality that other services need. If there was no RPC then those other services would have to implement this functionality themselves, instead of relying on a single well tested implementation.
The problem therefore is not with RPC, it's with those other services like DCOM, WMI etc. that are enabled by default and rely on RPC. If you are sure that you don't need any of these services, you can block RPC traffic using built in firewall or ipsec.
But if you want to be able to use some of these services (let's say WMI) then stop bitching about having to open RPC ports because if WMI implemented its own authentication layer it would have been less secure, not more.
I wasn't replying to the article. I replied to the person who said "all of the Windows exploits can reliably execute arbitrary system code" which is false.
RPCs are potential security risks...
RPC is not the problem, the problem is that too many network services are enabled by default.
But if each service implemented its own authentication mechanism instead of relying on RPC, things would have been even worse.
http://weblogs.asp.net/michael_howard/archive/2004 /10/18/244181.aspx
What's so special about the way Windows handles "security tokens"? If the exploit is in a component that runs as a limited user, you'll need an additional local root exploit to get System rights - same as in any other OS.
So, of the Linux exploits that are trivially available to exploit, none can reliably execute arbitrary system code, while all of the Windows exploits can.
Really? How?
I'm pretty sure IE doesn't do this. The reasonable thing to do is to let the application crash so that users can submit a crash report, and the problem can be fixed. Trying to continue execution after unhandled exceptions usually leads to undebuggable hangs.
I guess I really have no idea how one would authoritatively detect if the IE rendering engine has failed. Does anyone?
Run the process under debugger.
On W2K3 mstsc can connect to the console session (mstsc /console).
Better yet, use group policy. Go to User Configuration\Administrative Templates\Windows Components\Internet Explorer and enable these policies:
Disable changing homepage settings
Search: disable search customization
Windows Scripting Host supports SRPs so you can restrict access to .VBS/.JS files. For Perl and Java it would depend on how the runtime is implemented.
It's not specific to SP2 though; the change was in the original XP code base as well.
No it doesn't. From http://www.microsoft.com/technet/prodtechnol/winxp pro/maintain/sp2mempr.mspx:
Software-enforced DEP performs additional checks on exception handling mechanisms in Windows. If the program's image files are built with Safe Structured Exception Handling (SafeSEH), software-enforced DEP ensures that before an exception is dispatched, the exception handler is registered in the function table located within the image file.
It does some checks but only before an exception is dispatched, and only for binaries built with /SAFESEH switch.
After a power glitch you don't get the "Windows has recovered from a serious error... Do you want to submit error report to Microsoft?" dialog on the next boot.
BSODs can and do often happen as a result of hardware faults. The only way to find out if it's caused by hardware or Windows "flaking out" is to analyze the crash dump with a kernel debugger.
From http://www.microsoft.com/technet/security/bulletin /MS04-028.mspx:
An attacker who successfully exploited this vulnerability could gain the same privileges as the user. Users whose accounts are configured to have fewer privileges on the system would be at less risk than users who operate with administrative privileges.
IE runs just fine as a limited user.
In fact, when it comes to respecting the principle of the least privilege, IE is better than most Windows apps because it can even work with a restricted token (right-click IE shortcut, Run As..., Check the "Protect my computer" option).
In IIS6 no user code runs as System by default. ISAPI filters, ASP pages etc all run as Network Service.
RPC and RPC Locator services run as Network Service in SP2.
Messenger service is disabled by default in SP2.
Developing Software in Visual Studio .NET with Non-Administrative Privileges
And most of them can be made "compatible" simply by configuring an exception in the firewall. What's the big deal?
a hotfix released before the SP has even reached the masses
OK, so that's one legitimate (but low impact) bug discovered so far. Given the huge number of changes to the OS I'd say this is not that bad.
a much-hyped firewall that doesn't check outgoing connections (but pops up misleading dialogs that confuse the user into thinking it does)
The dialog says: "Windows Firewall has blocked this program from accepting connections from the Internet or a network". What's misleading here?
Not to mention the fact outgoing connection blocking can be trivially bypassed by malware. Implying that a software firewall can reliably prevent malware from calling home is what I'd call misleading.
quite a few people complaining about much strangeness after installing it
How many is "quite a few"? How many of these problems are because of bugs in SP2 as opposed to bugs in 3rd party software?
Personally, I haven't had any problems on my two XP machines.
Ntsd is already installed on all NT based systems, and can even be run without showing any UI.
That's not the point though - it all comes down to the fact that if you run a piece of native code then this code has the same privileges as you do. You have full control over what your processes are doing (you can debug your processes, you can inject arbitrary code into them, hide or change any part of their UI etc). So the malware can do all of this as well.
then any and all of those methods should be considered critical security flaws
Well, that's how native code works - any executable you run has the same rights as you do. Unless you restrict yourself to only running managed code (like .NET or Java) there's nothing you can do about it.
EXCEPT as SYSTEM! Not as Administrator, but SYSTEM!!
There is no differnce between System and Administrator from the security point of view. They both have full control over the entire OS.
And the Shift+F10 thing works during the GUI part of windows setup, it's not something specific to this particular dialog.
It's a GOOD thing. Outgoing connection blocking can easily be bypassed by worms or malware, it adds complexity to the firewall and trains users to click 'yes' on any security related message boxes. Leaving it out was the right thing to do.
It most certainly doesn't (unless you configure it to do so).
I don't disagree with the statement that the message WILL get out... however, I WILL know about it.
Unless, of course, I hide the window, or create it on an inactive desktop, or start the user's default browser under debugger and inject my evil code into it before it even displays the window.
Trying to prevent code that runs with the same privileges as the user from making outgoing connections is a waste of time.