Slashdot Mirror
Windows XP SP2 Could Break Some Applications
Denver_80203 writes "An article from InfoWorld states that the upcoming Windows XP Service Pack 2 could break some 'unsecure applications.' In a quote from Tony Goodhew, a product manager in Microsoft's developer group says 'It doesn't really matter how long it is going to take you to do the work; security is an important issue and developers need to start doing that work now.' Or: 'The great bulk of applications will not be affected by memory protection. The number one that leaps to mind is execution environments with just-in-time code generation. The .Net Framework is one.' Fortunately for us, they are offering a course to guide the unsecure masses."
Sounds like an issue with NX bit implementation on A64 ... this protects memory that is tagged as data from being executed (which protects against buffer overrun exploits, which are 50% of the MS security issues). This would affect .NET, Java, etc. However I'm sure that there is a way to fix this for these types of application!
Regardless, enforcing decent security like this is good.
Now all the hackers will have to try other methods of hacking windows, heh. I'm sure that there is no shortage of them!
Without doubt, countless QA software testers & coders will cry out in anguish over this.....more work for them to do. But if they want to sell their software on the large Windows desktop market....They have little choice in the matter.
For each software build, we have to test against the various OS versions, and different service packs builds. Not fun...
SP2 is not just another Service Pack. MS are using this as a means to introduce a lot of new stuff. everything from locked-down DCOM settings, to pop-up blockers and a new version of the Windows Installer.
A lot of stuff is going to break, but I think that this is good in a way. MS have finally put security ahead of backward compatibility. Once these changes are in place and apps are working with them, the system is going to be more secure. For once MS should be applauded - yes, you can argue it's a bit late, but at least they're doing it now.
If you want to check out what changes SP2 actually makes, have a read of this white paper:
Changes to Functionality in Service Pack 2 for Microsoft Windows XP
Lengthy, but worth a read, especially if you have apps that you think might be affected.
A downloadable version is available here.
Here's a list of a few applications that has been reported having problems in the latest betas of SP2, compiled from comments at Neowin when they posted these news:
- Zone Alarm 2 (uninstall stops working)
- BS Player (driver fail to load)
- Roxio Easy Media Creator 7
- Microsoft Intellipoint 5.0
- Azureus BitTorrent client
- ATI's Rage3DTweak for Radeon
- Easy CD Creator 5
- eMule
- Tritton NAS-120's Managment Interface
- Leadtek WINFAST TV PVR (driver fail to load)
- ISO Recorder Powertoy
Also, a user reports the Windows XP SP2 firewall blocking incoming FTP traffic even without an installed firewall, and XP's built-in disabled.
Maybe it's "beta diseases", but it does seem like a lot to break for a service pack, even in a beta. These are usually quite stable as they contain mostly bugfixes, not Win32 API changes (which these problems are supposedely caused by).
Beware: In C++, your friends can see your privates!
These folks write and consult and teach about Windows drivers. I've followed their newsletter ever since I had to write an NT kernel driver for some custom I/O hardware, in case I ever needed to do another one (blechh!).
According to their newsletter at www.osronline.com, XP SP2 will include mandatory runtime memory pool overrun checking for all drivers. While this will improve the OS' security, it will ALSO cause mysterious failures on upgraded systems due to poorly-written legacy XP drivers. I make no judgements as to the wisdom of this course, but it's definitely worth knowing about beforehand. Of course, if they'd done this FROM THE START, then there would be no failures from it with the upgrade...
"My strength is as the strength of ten men, for I am wired to the eyeballs on espresso."
Nope. If the NX flag catches your problem, it won't let it slide - it'll refuse to run that segment of code. So instead of a buffer overflow you can't see, now you'll have an exception that's a lot more visible, and a lot less dangerous if it slips by QA.
If Java is doing the right thing it will not be broken.
:).
The right thing to do is to call VirtualProtect(addr, size, PAGE_EXECUTE_READWRITE, &prevProtect);
That will mark the memory pages as being read/write/execute (where as previously they were only read/write). People should have been doing this before anyway (as the pages were never guaranteed to be executable), and if they didn't it's their bug.
I'm betting that Sun can download the beta and test Java on XP SP2 to make sure they're compliant though. Hell, Microsoft could probably even do some compatibility testing for them and enable a compatibility layer for Java. But then again Sun might sue them for that. MS probably just wants to stay away
Or you could just sit and blame Microsoft for your inability to read their supplied documentation pandering to a community that is as inept and continue to use the product without a clue as to how it works.
extra step (like the 'chmod u+x' required on *NIX)
.exe and locating the icon resource and displaying it, it is obvious that such thinking does occur to programmers and could easily have happened on Linux.
Hey I like Unix and dislike Windows, but this is a bit of Linux-fud. This is not some amazing "security feature" invented by K&R in 1970. Here are the facts:
1. A program can call "exec" on any file, whether or not it has the execute bit set. The system does not check, so this is not any real protection. Imagine a "Linux Outlook" written without any assumptions about security, the MS-style author of the program would certainly make it so that clicking on an executable would call exec or popen. The main security in Linux is that the email program writers never considered that somebody would want to run a program, they either save it as a file or open it as text. But considering that Microsoft went through the trouble of actually interpreting the attachement as a
2. Any program with permission to write the file can turn on the execute bit. For instance tar will restore the execute bits back on the tar'd files. A "user friendly" program would certainly turn on the bit on received files that indicated they want it, since that is what the user wants.
3. The real purpose of the execute bit:
When Unix was written in 1970, a powerful machine had 64K of memory and disks spun at a few hundred rpm. In addition the original design assummed executable programs and data files would be mixed together in the same directories. Especially the current directory: the idea that putting "." somewhere other than the start of the path for security did not occur till maybe 1980 (and it is still missing from Windows CMD.EXE!) Besides the current directory people would often modify their path to include their friend's home directories (to get their programs) or to get different versions of programs.
On such machines it would take many seconds to try to open a given file in each of several directories on the path. The only way to make a command run efficiently would be to store a hash table in memory saying which directory was the first on the path that each command was in (the command "rehash" in csh shells would recalculate this).
In the directory structure people were using then, over half the files on the path would not be executable and thus not commands. The rehash command could greatly reduce memory usage if it could eliminate these right away. The correct solution (opening the files and checking for magic execute bytes) would be far too slow. So they decided to dirty up the file system by adding a single "attribute" in the form of the execute bit, so the rehash could skip files quickly.
That is why the execute bit is there. It is not a security feature.