Running without a firewall is not smart, but not necessarily stupid, either. Once you run all the windows update patches, and disable file sharing on your WAN adapter (or at least use a good password and disable the guest account), what's left for people to hack?
So your hope is that you're never going to miss a patch? And that there never will be a 0-day exploit in LSASS, RPC etc? And you'll never install any programs that open a port without you knowing it immediately?
By the way, even if you don't see any pop ups from XP firewall it doesn't mean it's not working. As far as I can tell, pop ups are only generated for interactive programs that you run. Take a look at your security event log (you might need to enable 'detailed process tracking' in the auditing options first, I'm not sure). On my SP2 machine I see a bunch of messages from the firewall telling me that it has blocked several non-interactive services (such as SQL Server that I'm using for development) from listening on ports. I'm definitely not going to turn it off anytime soon.
nice to have a second opinion that 1433 is indeed unblocked from the client side on RC2.
XP firewall doesn't block outgoing connections, so of course 1433 doesn't need to be "unblocked" on the client (just like browsing the web doesn't require opening port 80).
If you had SQL Server running on an XP SP2 machine then you'd need to configure an exception for it, but SP2 clients shouldn't need any changes.
Here's some context for the "Linux is paying catch-up" thing. Back in 1999 Russinovich published an article where he compared Linux and NT kernels from the scalability point of view. He pointed out several things that Linux didn't have at the time (async I/O, zero-copy file sends, efficient thread pooling, reentrant kernel).
Today, most of these features have been implemented in Linux (even though AFAIK there's still no equivalent of NT's completion ports). This is what Russinovich means when he says that Linux has been playing catch-up - he doesn't talk about portability, security, etc, he's only looking at one particular side of things.
Some legitimate programs, such as Java compilers that perform just-in-time code generation, execute instructions within data areas -- and will have to be rewritten for Service Pack 2.
Of course, if those programs were written correctly in the first place they wouldn't need to be fixed to work on NX platforms.
Grandparent's point is that even if I choose to run as root...
Read his post again. He specifically complains that even on OSes where there is separation of user privileges, Outlook still somehow magically has "root access". Which is not true.
I run as root and I assure you that my web browser and email program most certainly do NOT do whatever they want.
The NT security model is that rights are granted to users, not programs. If you insist on using Outlook or IE while running as administrator you can limit what they can do by changing the user context they run under. For example, right-click the IE icon, select Run As... and choose a low privileged user or select the "Protect my computer..." option.
Of course it's still better not to run them as an admin in the first place.
The corperate help desk is stumped, and wants to (wait for it!) reinstall Windows. It's a W2K box, got any thoughts on how to fix this?
I don't know - may be start by using a debugger to figure out where the crash occurs? Or do you expect MS to provide you a menu option that says "Fix this for me"?
And I was questioning the tools to track the problem down: there are heaps of free debuggers and profilers than can help me track the problem down if it happens on linux
On Windows you could use windbg, kernrate and perfmon, to name a few.
In Windows, there are security features (designed to prevent users who don't have necessary privileges from doing things) and administrative features (designed to prevent clueless users from messing up their own stuff).
Disabling the "set as default page" button, or hiding cmd.exe from Start menu, or a multitude of other similar things are all administrative features. Yes, a determined user (or a malware program) can bypass these features but it doesn't mean they are useless.
When you see this message box it means the program is trying to listen for incoming connections. Windows firewall does not block outgoing connections, which is why you can still download stuff etc.
Sorry but no, there is no such mechanism in windows that would prevent this type of trojan. This signature mechanism will only protect you from someone altering the executable and trying to spoof with a valid MS signature. Nothing prevents windows from running unsigned executables.
Starting with XP you can use Software Restriction Plocy (SRP) which can do exactly this kind of things. Open up Local Security Settings under Administrative Tools and you'll find it.
With SRP you can allow or disallow execution based on certificates, hashes, paths, or internet URLs.
SRPs are probably not something that end users can be expected to configure but in a managed environment all these settings can be pushed to clients using group policy, and this is actually a very effective way to prevent trojans.
In earlier versions of Windows there is a window of time between when the network stack started and when ICF provided protection. Consequently, a packet could have been received and delivered to a service without ICF filtering it, potentially exposing the computer to vulnerabilities. In SP2, the firewall driver has a static rule called a boot-time policy to perform stateful filtering. This will allow the computer to perform basic networking tasks such as DNS and DHCP and communicate with a Domain Controller to obtain policy. Once the firewall service is running, it will load and apply the run-time ICF policy and remove the boot-time filters. This change should increase system security without affecting applications.
Of course, you need a second machine to use KD and a serial cable...
On XP and later you can do "local kernel debugging" (kd -kl). You can't control the target this way (set breakpoints etc) but most commands that work on dumps work in this mode as well.
This can be quite handy when you need to dive into kernel mode while troubleshooting something on a machne that wasn't setup for kernel debugging.
Consider how many windows programs use shared registry keys, consider how many read/write to common temp folders, or common locations on disk. Have any of the probably hundreds of overflows involved in reading a temp file from C:\Winnt\Temp been taken into consideration with WIndows?
And most of these shared locations are properly secured to begin with. If you can write to HKCU you can become the user, no need to exploit any buffer overflows. Same for HKLM - write access there is equivalent to having system/admin rights.
C:\winnt\temp is an interesting example. It's only used when profile is not loaded (otherwise your temp folder would be somewhere under Documents and Settings), but even then if you look at its security descriptor you'll see that files created by user A cannot be accessed by User B. The only way user B can hijack user A's temp files is if he can predict the name of the file that A is going to create, and manage to create the file in the short time window between the moment A checked that the file does not exist and the moment he calls CreateFile. And even then it will only work if A specifies "open existing" flag which is somewhat unusual for temp files.
In short, this is a valid attack vector but not nearly as bad as you made it sound.
wonder how many Winzip/Windows Compressed Folders have? NOBODY HAS EVEN LOOKED.
How do you know that? In fact I'm sure there have been a couple of similar exploits in the shell, and they have been fixed just like any other vulnerability.
If you want to reach more folks: Can we instead talk to a developer who wants to talk about the best way of doing things, rather than someone whose job is to come up with problems where MS is the solution?
http://blogs.msdn.com. Here you can find blogs from developers, tester, program managers, even MS job recruiters.
90% of these blogs are mostly junk (in my opinion) but a few are worth reading.
Because I can't prove my belief to be true without access to the code...
This might come as a surprize to you, but you don't need to see Word source code to figure out which OS functions it calls. You just look at the import address table of every Word binary (winword.exe, and all the dlls):
I was under the impression that the 1.5 year old Windows 2000 code recently leaked on the internet demonstrated that Microsoft applications were making use of undocumented OS APIs.
What does that prove? Of course there are internal functions in Windows that at one point or another were used by some MS applications. Do you suggest that MS remove these functions so that for example Word 6.0 no longer works?
What matters is that recent MS apps don't use any undocumented stuff. If you can find an undocumented function that is used by Word 2003 then you will have a point.
Lo, and behold, more and more initialization work for Office, and then IE, started showing up in the Windows boot sequence.
The Windows boot sequence is very well understood. See for example Inside Windows 2000 - there's a very detailed explanation of what's going on at boot time. Now, since you claim to know what you are talking about, can you point out where exactly is the "initialization work for Office and IE" done and what it consists of?
The APIs encourage bad security practice. Case and point: to put a user process inside a user sandbox, you have to get a handle on the user obeject from the OS.
And what exactly constitutes "bad security practice" here?
If you can, I would be very interested in how multiple concurrent users can run arbitrary userspace programs concurrently on XP.
Using fast user switching?
Presumably you meant to ask about concurrent *interactive* programs, and no, you can't do this in XP but it's not because the OS can't support it. Server OSes (Win2k and 2003) have had this functionality for years.
Slashdot Mirror
So your hope is that you're never going to miss a patch? And that there never will be a 0-day exploit in LSASS, RPC etc? And you'll never install any programs that open a port without you knowing it immediately?
By the way, even if you don't see any pop ups from XP firewall it doesn't mean it's not working. As far as I can tell, pop ups are only generated for interactive programs that you run. Take a look at your security event log (you might need to enable 'detailed process tracking' in the auditing options first, I'm not sure). On my SP2 machine I see a bunch of messages from the firewall telling me that it has blocked several non-interactive services (such as SQL Server that I'm using for development) from listening on ports. I'm definitely not going to turn it off anytime soon.
XP firewall doesn't block outgoing connections, so of course 1433 doesn't need to be "unblocked" on the client (just like browsing the web doesn't require opening port 80).
If you had SQL Server running on an XP SP2 machine then you'd need to configure an exception for it, but SP2 clients shouldn't need any changes.
Today, most of these features have been implemented in Linux (even though AFAIK there's still no equivalent of NT's completion ports). This is what Russinovich means when he says that Linux has been playing catch-up - he doesn't talk about portability, security, etc, he's only looking at one particular side of things.
Of course, if those programs were written correctly in the first place they wouldn't need to be fixed to work on NX platforms.
Win32 has always had PAGE_EXECUTE flag, and if you wanted to execute dynamically generated code you were supposed to include this flag when allocating memory (or use VirtualProtect afterwards).
Most people didn't bother with PAGE_EXECUTE because it wasn't enforced on x86. But technically it's always been required.
Read his post again. He specifically complains that even on OSes where there is separation of user privileges, Outlook still somehow magically has "root access". Which is not true.
I run as root and I assure you that my web browser and email program most certainly do NOT do whatever they want.
The NT security model is that rights are granted to users, not programs. If you insist on using Outlook or IE while running as administrator you can limit what they can do by changing the user context they run under. For example, right-click the IE icon, select Run As... and choose a low privileged user or select the "Protect my computer..." option.
Of course it's still better not to run them as an admin in the first place.
Huh? Outlook has the same privileges as the user running it.
You can do this on XP as well. %systemroot%\system32\eventquery.vbs %systemroot%\system32\eventtriggers.exe
I don't know - may be start by using a debugger to figure out where the crash occurs? Or do you expect MS to provide you a menu option that says "Fix this for me"?
On Windows you could use windbg, kernrate and perfmon, to name a few.
Disabling the "set as default page" button, or hiding cmd.exe from Start menu, or a multitude of other similar things are all administrative features. Yes, a determined user (or a malware program) can bypass these features but it doesn't mean they are useless.
When you see this message box it means the program is trying to listen for incoming connections. Windows firewall does not block outgoing connections, which is why you can still download stuff etc.
I'm running XP SP2 beta at home, and this is exactly what it does:
http://slashdot.org/comments.pl?sid=106651&thresho ld=0&commentsort=0&tid=109&mode=thread&cid=9077529
Of course, you can always port it to Watcom or any other compiler yourself... That's the beauty of open source, isn't it?
Starting with XP you can use Software Restriction Plocy (SRP) which can do exactly this kind of things. Open up Local Security Settings under Administrative Tools and you'll find it.
With SRP you can allow or disallow execution based on certificates, hashes, paths, or internet URLs.
SRPs are probably not something that end users can be expected to configure but in a managed environment all these settings can be pushed to clients using group policy, and this is actually a very effective way to prevent trojans.
http://msdn.microsoft.com/library/default.asp?url= /library/en-us/dnwxp/html/securityinxpsp2.asp
Boot time security.
In earlier versions of Windows there is a window of time between when the network stack started and when ICF provided protection. Consequently, a packet could have been received and delivered to a service without ICF filtering it, potentially exposing the computer to vulnerabilities. In SP2, the firewall driver has a static rule called a boot-time policy to perform stateful filtering. This will allow the computer to perform basic networking tasks such as DNS and DHCP and communicate with a Domain Controller to obtain policy. Once the firewall service is running, it will load and apply the run-time ICF policy and remove the boot-time filters. This change should increase system security without affecting applications.
By RTFM!
Or how about using google to search for "how to find out the specific registry keys the application accesses"?
Links #2 and #3 point to a free tool called RegMon which is even easier to use than the auditing approach.
On XP and later you can do "local kernel debugging" (kd -kl). You can't control the target this way (set breakpoints etc) but most commands that work on dumps work in this mode as well.
This can be quite handy when you need to dive into kernel mode while troubleshooting something on a machne that wasn't setup for kernel debugging.
WinDbg is free and in many aspects more powerful than the VC debugger.
And most of these shared locations are properly secured to begin with. If you can write to HKCU you can become the user, no need to exploit any buffer overflows. Same for HKLM - write access there is equivalent to having system/admin rights.
C:\winnt\temp is an interesting example. It's only used when profile is not loaded (otherwise your temp folder would be somewhere under Documents and Settings), but even then if you look at its security descriptor you'll see that files created by user A cannot be accessed by User B. The only way user B can hijack user A's temp files is if he can predict the name of the file that A is going to create, and manage to create the file in the short time window between the moment A checked that the file does not exist and the moment he calls CreateFile. And even then it will only work if A specifies "open existing" flag which is somewhat unusual for temp files.
In short, this is a valid attack vector but not nearly as bad as you made it sound.
wonder how many Winzip/Windows Compressed Folders have? NOBODY HAS EVEN LOOKED.
How do you know that? In fact I'm sure there have been a couple of similar exploits in the shell, and they have been fixed just like any other vulnerability.
http://blogs.msdn.com. Here you can find blogs from developers, tester, program managers, even MS job recruiters.
90% of these blogs are mostly junk (in my opinion) but a few are worth reading.
This might come as a surprize to you, but you don't need to see Word source code to figure out which OS functions it calls. You just look at the import address table of every Word binary (winword.exe, and all the dlls):
c:\>link /dump /imports "c:\Program Files\OFFICE11\WINWORD.EXE"
If you can find any undocumented functions in the output of this command then you might have a point.
(For completeness you also have to check for LoadLibrary/GetProcAddress but there are plenty of tracing tools that do that as well).
What does that prove? Of course there are internal functions in Windows that at one point or another were used by some MS applications. Do you suggest that MS remove these functions so that for example Word 6.0 no longer works?
What matters is that recent MS apps don't use any undocumented stuff. If you can find an undocumented function that is used by Word 2003 then you will have a point.
Lo, and behold, more and more initialization work for Office, and then IE, started showing up in the Windows boot sequence.
The Windows boot sequence is very well understood. See for example Inside Windows 2000 - there's a very detailed explanation of what's going on at boot time. Now, since you claim to know what you are talking about, can you point out where exactly is the "initialization work for Office and IE" done and what it consists of?
And what exactly constitutes "bad security practice" here?
Using fast user switching?
Presumably you meant to ask about concurrent *interactive* programs, and no, you can't do this in XP but it's not because the OS can't support it. Server OSes (Win2k and 2003) have had this functionality for years.