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."
Is this supposed to mean that Java will stop working?
--t
From the article @ Windows XP SP2 could break existing application
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.
Consensus is good, but informed dictatorship is better
Microsoft has a nice bit of info 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).
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.
...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.
"Klaatu, verada, necktie!" -Ash
He's not a programmer. This is important. From the end-user perspective, .NET is just a ill-formed buzzword. I do not doubt the idiocy of MFC (although I've never used it), and the improvement that .NET brings (although I've never used it), but as a Windows user, not developer, I can't see the difference or the point in installing the .NET framework.
The previous sig has been removed due to
yea but can windows protect its own memory?
(see blaster and the likes)
-- Karma: beyond good and evil - mostly affected by posting political
The real problem is that the benefits it (should) bring will not get deployed to the bulk of systems that need it - at 210Mb I can't see the majority of systems out there that really need it getting the whole thing downloaded, at least not within any reasonable time frame. Hopefully by the time it is actually released they will have a lite version on Windows update that can push the security improvements in a much smaller package.
Their decision to at least try to implement some long overdue fundamental improvements to the security of the architecture is to be welcomed no matter how over due it is. However despite that their decision not to add any outgoing filtering capability to the ICF doesn't make any sense to me and seems, well, just stupid really.
Backward compatibility has been a bit of a sacred cow in Windows for too long. Much of Windows' excess complexity and security deficiencies can be directly attributed to compromises made for the sake of compatibility with old applications.
Sounds like a rather nice way of introducing stability and or compatibility problems to java by not allowing Sun's Hot Spot just in time compiler to work correctly.
Got Code?
I know, I know. Don't feed the troll. You may think .NET is a failure, but there are a lot of companies who do not think so.
And if it was such a failure, why are the programmers in the open source computing community devoting the time and effort to make a linux version (mono, etc.).
And the same applies to java. "Download my free 175 KB java app" that requires a hefty download from sun. And that's just for one language.
However, I will agree that .NET is a really lame name.
~X
~X~
From the developer's guide. 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.
The only thing they get is the bottom line.. the biggest issues with Windows is spyware & viruses (for the majority of people). These are HUGE issues for both home and business users.
.. I have people using my system all the time -- everything from children to senior citizens (70+). The fact that I can install Linux MUCH EASIER than Windows (pop in Knoppix CD and initiate a HD install) and it doesn't have the two biggest problems that Windows has (spyware & viruses) and it has the "major apps" that are needed (web browsing, spreadsheets, word processors, email, im, etc..) is HUGE.
Here is what I see -->
My KDE 3.2 desktop ease of use is right up there with other operating systems
Microsoft is definitely getting it -- if they don't release quality products, their market share will erode.
Windows apps suffer from buffer overflows, Slashdot bags on Microsoft for having buffer overflows.
There is a biased nature on Slashdot, I'm not disputing that. Bagging though? Thats something like I'd see when someone goes on about something. Personally I like Microsoft products, but I am fully aware of their capacity to produce products laden with bugs and introduce service packs as a solution for this. IMHO Buffer Overflows are a bad thing and any company that produces programs that routinely has problems of this nature should be 'bagged' as you put it.
Windows adds NX security to prevent buffer overflows, Slashdot bags on Microsoft for breaking a few apps in the process (apps which were arguably broken in the first place, just the spec was never enforced).
Memory Security isn't a prevention of Buffer Overflows. Its containment. If the spec wasn't enforced, why? Aren't these issues exactly the kind of thing Microsoft should be addressing, otherwise how can even the service packs be sure to not contain the same mistakes?
The apps aren't broken, they work. Try and argue that they were broken then you're really saying anything with a buffer overflow vulnerability is essentially broken. Like parts of the operating system? Any system that has a fault, should not require something like a 120MB download to fix it.
The operating system is being fixed with what is essentially a big patch to stop buffer overflows, while breaking a lot of apps (not all from redmond surprise, surprise) in the process.
This will happen first, then if lucky they'll fix the apps.
There is a biased nature on this site, yes. Your post itself, albeit short contains a similar baised nature.
Myself, I don't really care about XP, I prefer Windows 2000 and although many will may argue differently have found Windows 2000 to be more stable and encountered less problems.
I only tend to move operating systems when the next version is more stable (after a period of use at work).
Im hoping that once .NET takes off, Outlook will only open .NET executables. Since they run in a VM, they can be restricted.
.NET exe directly over a windows share if you want to see it in action. If the program tries to access the local filesystem it gets an Exception).
You could configure it so all untrusted code was restricted.
(Try running a
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!
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Uhoh. Azureus is written in Java. Does that mean all Java apps will stop working?
Vote for global prefs bug
1) the 9X series of windows was able to run half-half-23-bit programs easier, because the OS WAS hanf-n-half. ever remember those "most switching benchmarks"? that was a benchmark to see how well your CPU could switch between the 16-bit and 32-bit instruction sets. 2) windows 2000 also supported the whole "application compatibility mode". go look for (i THINK its) appcompat.exe on the windows 2000 CD. it was an application w/ command lind params instead of being in the application's EXE's property menu. 3) as for compatibility w/ 16-bit applications, windows xp simply uses an emulator for 16-bit instructions. this is to make sure the memory arcetecture and other things dont break new pure-32-bit 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?
This appears to be the same "no-exec stack" idea that OpenBSD came up with some time ago.
.NET?
My question is, does Windows have an equivalent to the "mprotect()" call that can be used to override this, for, say, a Just-In-Time like Java or
My Norton Internet Security currently interferes with my Visual Studio .NET remote debugging. So I can disable it while debugging or I can configure NIS to track when the program is running and let it use those ports.
.Net Framework. The new memory protection features in SP2 require developers of certain applications to mark their code with memory execution permissions. If they don't, the protection features could interfere with the application, according to Microsoft.
.Net Framework is one," Goodhew said. "
.NET like we told you, you won't be affected. (But .NET apps are going to have to be modified to switch on memory protection)
.NET. (Which, last I checked, was the only way to make .NET objects that run on Windows). Without that flag turned on, the .NET object is marked UNSECURE.
.NET into the programming paradigm and making Microsoft Programming Languages THE programming languages. (Programmer mindshare... if you're busy keeping up with Microsoft, you're not programming for something else or making reusable code to port to other platforms.)
Now MS says, with their new firewall, I don't *have* that option? Now anybody who wants to write an app to use a port must first notify MS that it wants to use that port.
Doesn't this mean that malicious programs will just quietly open up firewall ports on their own without notifying the user?
Secondly, what does this mean:
"Another product that Microsoft needs to update is the
"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
Translation:
Mostly only unmanaged C++ programmers will be affected by these security changes. If you had just programmed the Microsoft way to begin with and used
Memory protection only occurs on NEW processors. The vast majority of the world runs Windows on NON-SECURE processors.
Stranger still, Microsoft has had buffer overrun checking BUILT IN to Visual Studio
Lastly, Microsoft's greatest security problems are not buffer overruns or firewall holes. They're AUTOMATIC ACTIVEX control installation from malicious pop ups to install spyware. They're wide open access to the email address box and a by-default scripting system that allows malicious emails to respawn themselves. They're bugs in the Internet Explorer control that allow malicious URL's.
NONE of these "security innovations" even take a crack at stopping those!
What DO these security innovations do?
Destroy a previously lucrative software market for antivirus tools.
Take the firewall OUT OF THE CONTROL of the user and put it firmly inside the OS to determine what's good for you. (Remember DRM? Isn't it interesting that the main thing broken from this portion of the update are peer-to-peer apps and FTP sharing?)
Further entrench
I'm all for security, and now these boxes will be secure... But no moreso than the typical user installation out there today that uses a third party antivirus/firewall solution and keeps their system up to date with the latest patches.
This is about as effective at what MS did with Outlook XP and *by default* turning off the ability to get attachments out of your email. You had to setup a profile configuration OR edit your registry settings to get that feature back.
Y'know, there comes a point where you have to say, I can ride my bicycle without training wheels.
I understand that MS is fighting a bad PR image. But if this is how Microsoft "innovates"... Well, might as well just have lightweight users use Macs (which will hold their hands) and pro users/developers can use Linux.
As an end-user, I will install a fresh copy of XP into VMWare, install all the apps I use on any of my machines and apply the fixpack.
If anything breaks, I will see if there are updates for my software available at no charge, if not, then I will not adopt the fixpack.
If this fixpack incur additional spendings on my part, then I will not use the fixpack, which means there will be at least a few machines out there "not fully up-to-date", with all the consequences of that in a globally connected environment.
I'd hate to be the "weak link", but if the vendors of my software do not provide free updates, too bad for the rest of you.
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.
Yes. Python doesn't (currently) do any kind of JIT compiling and is therefore purely an interpreted language and won't be affected by this change. To explain a bit further:
Basically we can divide programming languages (and environments) into compiled languages and interpreted languages. Compiled languages are usually fast but in many ways unsafe and the resulting programs are harder to observe. Interpreted languages are slow but observing and debugging the program is easy. Also a compiled program can only be run on a single architecture without recompiling while interpreted programs can be run on any architecture for which an interpreter exists.
Now there's a special class of languages that are compiled to bytecode which is closer to actual machine language than the source code yet independent from architecture. The resulting bytecode is run in a virtual machine (VM), which still has to interpret or compile it.
Often interpreting the bytecode is even slower than interpreting the original language. However, compiling the code and then running it only once is usually even slower than interpreting. The solution is to compile the code just in time (JIT) when it has possibly already been interpreted a few times and it seems likely it will be executed again and again. This way only the speed-critical parts of the program will ever be compiled, resulting in performance (arguably) close to compiled languages without tying the program to a single architecture.
Now, just as for any other compiler, from the JIT compiler's point of view both the bytecode and the compiled, machine-executable code is pure data. So the problem arises when the VM suddenly wants to transfer control from its interpreter code to the JIT-compiled code. The operating system has taken care of marking all the VM code as "OK to execute" when the program was started, but now no-one, unless the VM, has told the operating system that the new code is OK to execute. Therefore the OS cannot distinguish it from a case where a malicious user has fed machine code to a program as data and used a flaw in the program to jump into it, which is the way most common exploits work.
As for Python, I wouldn't actually classify it into bytecode languages, at least not yet. AFAIK the "bytecode" that Python scripts can be compiled into is more like a parse tree of the program than machine code, and the Python interpreter still purely interprets it. No generated machine code is executed at any point in time and hence the above scenario doesn't apply.
In languages like Python that can treat code as data, the code is not stored in the binary form the CPU executes, but as a list of instructions for the language's interpreter. So, as far as the CPU is concerned, those pieces of code are really data. .NET JIT. It will have to be aware of the NX flag and set it explicitlly.
If the code was compiled beforehand, then the reference to the code structure will be a pointer to the actual function, stored with the rest of code.
If the language has a JIT (just-in-time compiler), it has a risk of being broken, as mentioned earlier with the
It's not a language problem, it's an issue with compiler implementation and CPU design. Stack overflows, heap overflows, integer overflows, etc allow execution of code because of the way the machine code runs and the architecture of the CPU. It can be fixed without changing the language or using some obscure language.
MSFT refuses to do more hiring to increase the number of people they have doing application compatability testing.
They also refuse to increase the number of people who work **full-time** in "sustained engineering". (I.e. the people who are supposed to be supporting shipped releases, so that the core Windows team can work on Longhorn.)
And the application compatibility testing team, while very good at what they do, can only cover so much ground so fast. Holding up XPSP2 solely to do app compat testing and the dev work to fix bugs they find is not acceptable. Especially when most of the things that are not being tested or that have problems, are either marginal products or (as others pointed out) just don't have companies behind them anymore.
Also, just like getting close to shipping any other software: much bigger issues that normally would have gotten into a service pack have been postponed or denied altogether. This is so that MSFT can do more security fixes or just get the code base stable enough for final testing and ship. That particular thing isn't necessarily solved with more people, but it is a fact of life when getting ready to ship.
So you compromise on something. In this case, it ain't gonna be security work, and it ain't gonna be XPSP2's ship date.
My last gripe on this point: When a company with $40+ billion in the bank refuses to spend it on more people, yet thinks they can have the same core development team do 4 - 5 major releases simultaneously, something's gotta give. For Longhorn, it was a firm ship date; for SP2, it's application compatibility.
No, I don't work on the app compat team. Yes, I work for MSFT.
1) There are some obvious security problems with the OS and some applications. Obvious like allowing MSHTML in Outlook. Allowing MSHTML in anything with admin priveleges is bad.
2) Windows in a default installation leaves thing waiting to be maliciously altered. Most users don't need admin priveleges, so why give them to everyone? There are other examples (like no default passwords on user accounts - admin accounts).
3) MS doesn't like fixing things. They seem to avoid it. IE is the classic example. MS has the largest installed browser base, and IE is one of the worst browsers. They are just screwing their customers there. MS: Just buy out Opera and use that, please.
4) Windows and most (if not?) everything MS owned is closed source. So not only does /. not like it, but geeks can't have their special way with their computer. There are huge benefits to open source of course, besides our curiousity and fetish for improvement.
5) MS doesn't patch security concerns or general bugs, and then goes around and tells people they have extremely fast return on necessary patchs and that their focus is on security. Well nobody really believes that, so MS is talking to itself and paying people to say it back to them.
6) MS is a big, rich corporation who has tried to take over a few industries at least.
for me if MS are still insisting on the EULA that authorizes (or a least claims to authorize) MS to install software without my knowledge. Has anyone who has read the SP2 EULA confirm whether or not it is a part of the agreement?
As of 1 week ago the internet explorer update Q832894 causes MSN 8.x and 9 to have an internal error on load. If MS can't even keep compatability with their own software what hope do third party vendors have.
Yep. I get the occasional "Microsoft is everywhere, so why bother?" comments, and I've gotten into the habbit of either smiling and not saying a word or giving a demo and not commenting on Microsoft at all. Silence or not contradicting them makes people curious and I don't have to spend time arguing this over this type of sillyness.
As for switching folks over, I've had sucess with my father after I installed Firefox (when it was Pheonix) and gave both he and my mom a 10 minute demo.
What really did it though is that I first found out what sites they like to visit, put them a bookmark, and set the home page to the bookmark. After they switched, I cut the confusion even more by using a custom wallpaper that has text on it with arrows ("click this to connect to the Internet", ...).
He is concerned about security now, but won't leave Windows. He is hoping that I have a silver bullet that can prevent his financial information from being stolen...and while I am thinking about that, I also know that neither of them want to have any changes at all to what they have.
Having said all that, demos don't always sink in. For example: One person kept referring to KDE on my laptop as XP. I must have said "I'm not running Windows; this is KDE and Linux; Not XP." about 30-40 times over 3 weeks before it sunk in. He even kept calling KDE XP moments after I told him it wasn't!
The same person keeps thinking that the web cam he has will work perfectly if only he gets a faster computer...though he and his family in another country have dial up. No demo of that fact, so it is taking even longer.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
.NET was always targetted for developers anyway. Users won't need to know about .NET.
.NET is replacing Win32 itself. The reecent betas are already running explorer.exe as managed code. So, users won't need to install the .NET framework because it will be part of Windows itself.
In Longhorn,
Right now, it's just a development framework to get used to.
"Sufferin' succotash."
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.
I mean, let's say that MS releases a new version of Windows that is totally incompatible with the old version. Nothing from the old version runs. What will happen? No one will buy it. It's not like the old version will stop working, they'll just keep using it.
Even WITH all the backward compatibility they have all hell getting people to upgrade. NT4 is now about 8 years old. What's more, Windows 2000 or XP are basically ideal replacements for it. They support everything NT4 did and more. Also, since they are just newer versions of the same architecture, you have almost 0 compatibility problems. In fact there are plenty of Windows 95/98 apps that wouldn't run in NT4 that run fine in 2k/XP. Finally, MS has discontinued support of NT4, what with it being 8 years old and succeded by 2 OSes.
So no one uses NT 4 any more, right? Wrong. There are still plenty of bussinesses that are dragging their feat and whining about MS cutting off support "so soon". Basically it comes down to money (they are too cheap to buy an upgrade) and the fact that it still works fine for them.
So it is highly in MS's intrest to keep their OSes backward compatible. They want that all a customer's apps will run in the current version, so there is basically no excuse (other than money) not to upgrade.
Also think about it: If MS totally broke compatibility with old versions, why not move to Linux? I mean either way you are talking needing all new apps, and Linux actually HAS some apps and is free.
No, I imagine they'll continue to support legacy software to the best of their ability.