Drivers typically run in kernel mode. Kernel mode simply can't be "secure". Those drivers can do anything the kernel can do, including write directly to memory (ANY memory), disk, etc.
This applies any ANY OS that allows code to be loaded into the kernel... in other words, allows kernel mode drivers.
Every computer accused of piracy is unable to recieve security updates, making it that much more likely to be hit with malware and therefore become a transmitter of such. The more transmitters, the faster the virus spreads.
This is false. Machines that fail WGA cannot download OPTIONAL/NON-SECURITY RELATED updates. Security updates have been, and always will be, available for download by ANY machine regardless of its legal state.
Despite the fact that your claim has been echoed by many, many others, it remains false.
Give me a break. The fact that WGA missed a pirated copy of Windows is absolutely not evidence that it doesn't work as it should.
The vast majority of WGA checks have to do with simply checking for known pirated keys. This particular key hadn't been picked up by Microsoft yet.
WGA missing this pirated copy is not the same as it falsely accusing a users of pirating a copy that is legit. The former will probably happen often, the later is extremely rare.
As much as many of you would like to believe that the reason this demo failed was because Microsoft code is horribly designed and implemented, and that they are completely incompetent, there just might be a slightly more realistic explanation for the demo's abject failure.
According to Rob Chambers, a developer on the Vista speech recognition team, the failures during the demo were caused by audio gain issues.
From his blog:
If you watch the video clip on MSN Video you can see in the speech user interface that the microphone "volume" is very high. It pushes up into the red frequently while Shanen is speaking to the computer. That's caused by the fact that the audio sub-system wasn't respecting the audio gain settings we've asked it to use.
This is a known bug in current builds, and has already been fixed by the audio team in their private builds in preparation for RTM.
Read the entire blog post for a more complete explanation of what happened... one that's just slightly more plausible than most of the explanations proffer by your fellow Slashdotters.
First of all, the update is OPTIONAL. The only thing that is "pushed" to the client via Windows Update is an installer shim. When it runs it prompts the user and asks them if they would like to install an update for IE. They can say Yes, No, or Ask Me Later.
Second, guess what I was greeted with this morning when I came in to work? It was a Firefox dialog saying that I was already updated to the new version and would I like to restart firefox so the changes could take effect. How is this really any different? Does anybody have knowledge that version 2.0 of Firefox won't be pushed this way, just like version 1.5.0.5 was today?
Could IE7 have bugs? It almost certainly does... but the fact of the matter is that it has some very important security related design changes and fixes that will make Windows users safer. If large e-commerce sites are worried about how their pages will display in IE7, why don't they download a copy of the freely available beta and test it?
Microsoft's decision to push IE7 out via Windows Update is a good one not just because of the security reasons, but because it will move a huge percentage of the people on the web to a browser with far better standards support. The lag time between standards adoption will be dramatically reduced. Let's face it, a big reason that many sites aren't standards compliant today is because of IE. If Microsoft simply offered it as a download on their web site it would take years for adoption to reach high enough levels to stop coding for IE6.
But there IS A SECURITY MECHANISM. It's just not at the level of the window or application. It's at the level of the desktop.
different queues for different tasks: GUI messages in one queue, app messages in other queues.
I'm not sure I understand what you mean by GUI messages vs app messages. Is a WM_SETTEXT a GUI message and a WM_TIMER an app message? Please define the difference.
check security on the first access. You don't need to check security each time the mouse moves.
But you do. The mouse move message was an arbitary example of a window message that happens very frequently. What about WM_NCPAINT, WM_DRAWITEM, WM_SETCURSOR, or WM_MyCustomMessageHere? You can't tell if the message is dangerous because what the message does is different on an app by app basis, and you can't simply do a security check "on the first access" because that statement is meaningless.
use an abstraction with a unified security mechanism like FILES instead of queues
Windows has a security subsystem that allows you to assign security to many kinds of objects, far more than just files. They could have easily assigned security to window messages. The point is that it would KILL PERFORMANCE. In Vista, Microsoft has taken a different approach and dramatically restricted the way that messages can be sent from application to application in general. They still didn't apply ACLs to window messages, but this will effectively elliminate any threat, despite the fact that virtually no application expose this problem.
The Win32 messaging system is a huge design flaw. In fact, Win32 IS A HUGE DESIGN MISTAKE. Please Microsoft, DROP WIN32 and write something that makes sense!
So now not only is the windows message system a huge design flaw, but the entire win32 api is? Wow, quite the jump.
Nope, you just dismissed it on the basis of it being in a Wikipedia article.
No. I first made a jab at the original poster treating something in wikipedia as if it were fact, and then then gave a specific reason why I dismissed it. My reason for dismissing it had nothing to do with wikipedia and everything to do with it being wrong.
I said:
"Design flaw" suggests that they didn't consider this scenario. This is false. They absolutely did consider this scenario and decided it was still a good decision due to the performance implications. The developer documentation clearly warns against displaying high-priv GUI on a low-priv desktop.
I did refute the statement, not to mention the fact that the statement is called into question in the very same wikipedia article that was cited.
Anybody familiar with Windows programming knows about the security issues surrounding window messages. They know that the security boundary is at the desktop level, not the window or application level.
I completely agree with you that it's a problem that security related dialogs in XP are clickable by malware even if it's running as the current user.
But you have to remember that the only way that dialog will affect the entire system is if the user is running as admin, and if the user is running as admin the malware likely is to... so they don't really have to simulate clicks to do their damage.
Ah, so a wikipedia article proves that it's a design flaw in Windows?
In that case, I'm going to post a wikipedia article stating that your a midget. It's gonna be tough living out the rest of your life as a little person.
"Design flaw" suggests that they didn't consider this scenario. This is false. They absolutely did consider this scenario and decided it was still a good decision due to the performance implications. The developer documentation clearly warns against displaying high-priv GUI on a low-priv desktop.
You would be very hard pressed to find a major/popular application available today that makes this attack possible. It wasn't that common to begin with, and after Microsoft's warnings, it's virtually non-existant.
This "shatter attack" has been known about and acknolwedge for MANY YEARS. (Long before the 2002 paper cited in this thread.) Every once in a while people will bring it up as proof that Windows has design flaws.
This was a design decision with known trade-offs. Attaching security tokens to window messages would result in MAJOR overhead that would, even on today's beefy hardware, kill performance. Having to do a permissions check every time the mouse is moved is not feasible.
So Microsoft decided that they would rely on "best practices" information as apposed to enforced security in the OS to prevent "shatter attacks". The best practices are pretty simple: If your service/application is running with elevated permissions (such as SYSTEM), do not display a GUI on a desktop owned by a lower privledged user.
There have been examples of applications, in particular some poorly written anti-virus applications, that liked to display GUIs to the user despite the fact they were running as SYSTEM. For the most part, however, very few major applications exist today that have this issue.
Applications that run with high privs that need to display a GUI typically launch their GUI with the privs of the user, or display the GUI on a secure desktop. (Like Winlogon.exe.)
This is really a non-issue and hasn't been for a very long time. Please, ignore the FUD.
You do realize that every time you use "M$" fewer and fewer people could care any less about what you have to say, right?
You attribute Microsoft's actions to greed... guess what, THEY ARE A FOR PROFIT COMPANY. Greed is another word for the desire for profits.
The decisions Microsoft made were the correct ones AT THE TIME they made them. In 1992, when Microsoft began what would become Windows 95, they didn't see the Internet coming. By the time they realized that the net posed a security risk it was far too late to redesign Windows and have any hope of making real money on what was then one of the most expensive software projects in history.
You speak of "virtual machines" and claim that these were feasible on 386 hardware. First of all, you really must be delusional. Virtual machines are becoming popular today because hardware is finally at a point where the performance is expectable. Do you honestly believe this was the case 12 or 15 years ago? Second, I think you are dramatically underestimating the scope of creating an embedded virtual machine in the OS to run legacy applications. Even if Microsoft were to accomplish this, it would be at the expense of new features and improvements that customers demand.
You specifically said that Microsoft has claimed that users running as admin was never a problem, but your only support is the fact they use the terms "enterprise ready" or "internet ready". Give me a break. Next you'll claim that anybody who criticizes the President wants terrorists to destroy America. You and I both know that in no way means that Microsoft thinks it's not a problem, not to mention the fact that it is ENTIRELY possible to run XP without admin privs if you don't mind legacy apps often breaking. I run my home machines without admin privs once I've got them setup the way I want them. The only time I'm forced to elevate to admin is when I'm doing certain debugging tasks that require privs only available to admins.
Lastly, you claim that I'm revising history... yet you offer not a single fact that discounts what I've said. You appear to see history through your warped anti-MS prism. It's time to take a step back and ask yourself what you're doing here. Do you so need to believe in the boogey man that you're willing to disregard fact to do so? Sounds and awful lot like religion to me... anti-MS religion.
The blame for applications that needlessly require Administrator privileges lies 100% at the feet of the people that write such software.
I would say that the blame is more like 70% developers, 30% Microsoft. Yes, it's been easy to write software for Windows that works properly in a multi-user, non admin scenario. But without any real guidelines (until the Windows Logo program, which didn't debut until long after the XP launch), and without any serious push from Microsoft, developers had little reason to do so.
Microsoft has to take some of the blame. They're so good at getting developers to go with the flow in other areas, but not this one.
I know it's hard sometimes, but please try and actually read the post you're responding to before ranting:
Once a program is running, it can do anything, up to the limits of what you yourself can do on the computer.
As far as Windows being the only OS where the user is admin by default, you're correct. Of all modern operating desktop systems, Windows XP is the only one to make the first user admin by default. But did you ever ask yourself why?
You claim it's a simple matter of "twenty years of fraudulent marketing bullshit trying to claim it wasn't a problem". Find me a single example of this. You can't, because you just made it up.
The fact of the matter is that Windows has a very long history on the desktop, and for a large percentage of that history they haven't even had memory isolation or a permissions system. (Read: Win X.XX, Win 9x, Win ME.) In Microsoft's defense, the Internet took them a bit by surprise. Until the Internet, desktop security wasn't an issue for anybody except businesses, and that's why they used NT.
Over those years many, many, many applications were written for those flavors of Windows. These applications all assumed they were running as admin, and for good reason... they were! It wasn't until just 5 years ago that Microsoft finally made the push to get consumers on to the NT kernel, with all its nice security features and the new world of multiple users with varying permissions. Ut oh. There in lies the problem. Microsoft couldn't simply make users non-admin by default because now almost all existing desktop applications, the very thing people buy Windows for in the first place, would break.
So Microsoft had to make a hard choice... break all existing applications and go out of business, or have the users run as admin by default. Tough choice.
Admittedly, Microsoft should have done a MUCH better job over the past 5 years to get people to develop Windows applications the correct way. Aside from their "Logo Certification", they've done almost nothing.
Vista's UAC is a huge step forward for Windows, and it solves a very difficult technical problem that is absolutely unique to Windows: a massive legacy software library dating back 20+ years that *must* run flawlessly on every new version of Windows. Microsoft does not have the luxury of breaking every existing application like Apple does (thanks to their extremely small, yet insanely loyal user base), nor do they have the pleasure of having a software library written with multi-user systems in mind from the get-go, like Unix/Linux.
Cleary this isn't as simple as Microsoft being "fraudulent", nor is it "marketing bullshit", and they certainly have never claimed it wasn't a problem.
Since you obviously had no interest in reading the link that my paraphrase was refering to, here it is:
Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore
It's an unfortunate fact of computer science: when a computer program runs, it will do what it's programmed to do, even if it's programmed to be harmful. When you choose to run a program, you are making a decision to turn over control of your computer to it. Once a program is running, it can do anything, up to the limits of what you yourself can do on the computer. It could monitor your keystrokes and send them to a website. It could open every document on the computer, and change the word "will" to "won't" in all of them. It could send rude emails to all your friends. It could install a virus. It could create a "back door" that lets someone remotely control your computer. It could dial up an ISP in Katmandu. Or it could just reformat your hard drive.
That's why it's important to never run, or even download, a program from an untrusted source--and by "source," I mean the person who wrote it, not the person who gave it to you. There's a nice analogy between running a program and eating a sandwich. If a stranger walked up to you and handed you a sandwich, would you eat it? Probably not. How about if your best friend gave you a sandwich? Maybe you would, maybe you wouldn't--it depends on whether she made it or found it lying in the street. Apply the same critical thought to a program that you would to a sandwich, and you'll usually be safe.
As you can see, the adage in question is perfectly reasonable and applies to everybody, not just Windows users.
I'm not sure that's true (I think I remember hearing about an x64 proof of concept root kit), but even if that is true it's just because the layout of OS components in memory has changed.
Getting around this is simply a matter of coding for it.
The Address Space Randomization, however, would make this very, very hard.
I think it's somewhat disingenuous to specifically note this rootkit works in Vista. It implies that the security work done in Vista has somehow failed.
Vista has numerous improvements security wise, and almost all of them have to do with prevent a machine from becoming infected to begin with.
I don't know if developers are taking advantage of it, or to what extent it supports it, but I'm fairly sure the Xbox 360 already has Procedural Synthesis capabilities.
Ya, I wouldn't want to pay that either. Luckily, Windows doesn't cost that much money.
Windows Server 2003 Web Edition, 32-bit version - $399 Open NL Windows Server 2003 R2 Standard Edition - $999 (5 CALS) Windows Server 2003 R2 Standard Edition - $1,199 (10 CALS) Windows Server 2003 R2 Enterprise Edition - $3,999 (25 CALS)
You can also get licenses for a lot less than retail on eBay, and it's perfectly legal. I've purchased Web Edition for as little as $200, and Enterprise for $1200. There are lots of companies who buy these things in bulk and end up not using them.
In addition, if you're not hosting an external site (customer facing) you can get an Action Pack subscription for about $300 that gives you access to up to 5 licenses for each of these OS's.
I agree. In fact, I'm a fan of a lot of Microsoft stuff. (*ducks*) I've developed systems that were blazing fast and were written with.NET.
I'm just saying that, in this case, the benchmark is completely useless. It would be like conducting a drug trial to determine if a particular drug works, but letting the participants also take any other drugs they want in addition to smoking some crack on the weekends.
Slashdot Mirror
Drivers typically run in kernel mode. Kernel mode simply can't be "secure". Those drivers can do anything the kernel can do, including write directly to memory (ANY memory), disk, etc.
This applies any ANY OS that allows code to be loaded into the kernel... in other words, allows kernel mode drivers.
This is false. Machines that fail WGA cannot download OPTIONAL/NON-SECURITY RELATED updates. Security updates have been, and always will be, available for download by ANY machine regardless of its legal state.
Despite the fact that your claim has been echoed by many, many others, it remains false.
Give me a break. The fact that WGA missed a pirated copy of Windows is absolutely not evidence that it doesn't work as it should.
The vast majority of WGA checks have to do with simply checking for known pirated keys. This particular key hadn't been picked up by Microsoft yet.
WGA missing this pirated copy is not the same as it falsely accusing a users of pirating a copy that is legit. The former will probably happen often, the later is extremely rare.
Or maybe people don't bash Steve Jobs and Apple after failures like they do Bill Gates and Microsoft.
According to Rob Chambers, a developer on the Vista speech recognition team, the failures during the demo were caused by audio gain issues.
From his blog:
Read the entire blog post for a more complete explanation of what happened... one that's just slightly more plausible than most of the explanations proffer by your fellow Slashdotters.
First of all, the update is OPTIONAL. The only thing that is "pushed" to the client via Windows Update is an installer shim. When it runs it prompts the user and asks them if they would like to install an update for IE. They can say Yes, No, or Ask Me Later.
Second, guess what I was greeted with this morning when I came in to work? It was a Firefox dialog saying that I was already updated to the new version and would I like to restart firefox so the changes could take effect. How is this really any different? Does anybody have knowledge that version 2.0 of Firefox won't be pushed this way, just like version 1.5.0.5 was today?
Could IE7 have bugs? It almost certainly does... but the fact of the matter is that it has some very important security related design changes and fixes that will make Windows users safer. If large e-commerce sites are worried about how their pages will display in IE7, why don't they download a copy of the freely available beta and test it?
Microsoft's decision to push IE7 out via Windows Update is a good one not just because of the security reasons, but because it will move a huge percentage of the people on the web to a browser with far better standards support. The lag time between standards adoption will be dramatically reduced. Let's face it, a big reason that many sites aren't standards compliant today is because of IE. If Microsoft simply offered it as a download on their web site it would take years for adoption to reach high enough levels to stop coding for IE6.
3) there is no security mechanism
But there IS A SECURITY MECHANISM. It's just not at the level of the window or application. It's at the level of the desktop.
different queues for different tasks: GUI messages in one queue, app messages in other queues.
I'm not sure I understand what you mean by GUI messages vs app messages. Is a WM_SETTEXT a GUI message and a WM_TIMER an app message? Please define the difference.
check security on the first access. You don't need to check security each time the mouse moves.
But you do. The mouse move message was an arbitary example of a window message that happens very frequently. What about WM_NCPAINT, WM_DRAWITEM, WM_SETCURSOR, or WM_MyCustomMessageHere? You can't tell if the message is dangerous because what the message does is different on an app by app basis, and you can't simply do a security check "on the first access" because that statement is meaningless.
use an abstraction with a unified security mechanism like FILES instead of queues
Windows has a security subsystem that allows you to assign security to many kinds of objects, far more than just files. They could have easily assigned security to window messages. The point is that it would KILL PERFORMANCE. In Vista, Microsoft has taken a different approach and dramatically restricted the way that messages can be sent from application to application in general. They still didn't apply ACLs to window messages, but this will effectively elliminate any threat, despite the fact that virtually no application expose this problem.
The Win32 messaging system is a huge design flaw. In fact, Win32 IS A HUGE DESIGN MISTAKE. Please Microsoft, DROP WIN32 and write something that makes sense!
So now not only is the windows message system a huge design flaw, but the entire win32 api is? Wow, quite the jump.
So it's a design flaw because it's a design flaw? Or is it a design flaw because you say so?
I've given reasons why I believe, and the majority of people who have a clue believe, this is not a design flaw.
You, however, have just relied on circular logic and "because I say so" reasoning.
I feel sorry for people like you... trapped into a corner by your own bias and intellectual dishonesty.
No. I first made a jab at the original poster treating something in wikipedia as if it were fact, and then then gave a specific reason why I dismissed it. My reason for dismissing it had nothing to do with wikipedia and everything to do with it being wrong.
I said:
I also posted a more complete response here: http://slashdot.org/comments.pl?sid=191497&cid=15
I did refute the statement, not to mention the fact that the statement is called into question in the very same wikipedia article that was cited.
Anybody familiar with Windows programming knows about the security issues surrounding window messages. They know that the security boundary is at the desktop level, not the window or application level.
I completely agree with you that it's a problem that security related dialogs in XP are clickable by malware even if it's running as the current user.
But you have to remember that the only way that dialog will affect the entire system is if the user is running as admin, and if the user is running as admin the malware likely is to... so they don't really have to simulate clicks to do their damage.
Ah, so a wikipedia article proves that it's a design flaw in Windows?
In that case, I'm going to post a wikipedia article stating that your a midget. It's gonna be tough living out the rest of your life as a little person.
"Design flaw" suggests that they didn't consider this scenario. This is false. They absolutely did consider this scenario and decided it was still a good decision due to the performance implications. The developer documentation clearly warns against displaying high-priv GUI on a low-priv desktop.
You would be very hard pressed to find a major/popular application available today that makes this attack possible. It wasn't that common to begin with, and after Microsoft's warnings, it's virtually non-existant.
This "shatter attack" has been known about and acknolwedge for MANY YEARS. (Long before the 2002 paper cited in this thread.) Every once in a while people will bring it up as proof that Windows has design flaws.
This was a design decision with known trade-offs. Attaching security tokens to window messages would result in MAJOR overhead that would, even on today's beefy hardware, kill performance. Having to do a permissions check every time the mouse is moved is not feasible.
So Microsoft decided that they would rely on "best practices" information as apposed to enforced security in the OS to prevent "shatter attacks". The best practices are pretty simple: If your service/application is running with elevated permissions (such as SYSTEM), do not display a GUI on a desktop owned by a lower privledged user.
There have been examples of applications, in particular some poorly written anti-virus applications, that liked to display GUIs to the user despite the fact they were running as SYSTEM. For the most part, however, very few major applications exist today that have this issue.
Applications that run with high privs that need to display a GUI typically launch their GUI with the privs of the user, or display the GUI on a secure desktop. (Like Winlogon.exe.)
This is really a non-issue and hasn't been for a very long time. Please, ignore the FUD.
You do realize that every time you use "M$" fewer and fewer people could care any less about what you have to say, right?
You attribute Microsoft's actions to greed... guess what, THEY ARE A FOR PROFIT COMPANY. Greed is another word for the desire for profits.
The decisions Microsoft made were the correct ones AT THE TIME they made them. In 1992, when Microsoft began what would become Windows 95, they didn't see the Internet coming. By the time they realized that the net posed a security risk it was far too late to redesign Windows and have any hope of making real money on what was then one of the most expensive software projects in history.
You speak of "virtual machines" and claim that these were feasible on 386 hardware. First of all, you really must be delusional. Virtual machines are becoming popular today because hardware is finally at a point where the performance is expectable. Do you honestly believe this was the case 12 or 15 years ago? Second, I think you are dramatically underestimating the scope of creating an embedded virtual machine in the OS to run legacy applications. Even if Microsoft were to accomplish this, it would be at the expense of new features and improvements that customers demand.
You specifically said that Microsoft has claimed that users running as admin was never a problem, but your only support is the fact they use the terms "enterprise ready" or "internet ready". Give me a break. Next you'll claim that anybody who criticizes the President wants terrorists to destroy America. You and I both know that in no way means that Microsoft thinks it's not a problem, not to mention the fact that it is ENTIRELY possible to run XP without admin privs if you don't mind legacy apps often breaking. I run my home machines without admin privs once I've got them setup the way I want them. The only time I'm forced to elevate to admin is when I'm doing certain debugging tasks that require privs only available to admins.
Lastly, you claim that I'm revising history... yet you offer not a single fact that discounts what I've said. You appear to see history through your warped anti-MS prism. It's time to take a step back and ask yourself what you're doing here. Do you so need to believe in the boogey man that you're willing to disregard fact to do so? Sounds and awful lot like religion to me... anti-MS religion.
I would say that the blame is more like 70% developers, 30% Microsoft. Yes, it's been easy to write software for Windows that works properly in a multi-user, non admin scenario. But without any real guidelines (until the Windows Logo program, which didn't debut until long after the XP launch), and without any serious push from Microsoft, developers had little reason to do so.
Microsoft has to take some of the blame. They're so good at getting developers to go with the flow in other areas, but not this one.
As far as Windows being the only OS where the user is admin by default, you're correct. Of all modern operating desktop systems, Windows XP is the only one to make the first user admin by default. But did you ever ask yourself why?
You claim it's a simple matter of "twenty years of fraudulent marketing bullshit trying to claim it wasn't a problem". Find me a single example of this. You can't, because you just made it up.
The fact of the matter is that Windows has a very long history on the desktop, and for a large percentage of that history they haven't even had memory isolation or a permissions system. (Read: Win X.XX, Win 9x, Win ME.) In Microsoft's defense, the Internet took them a bit by surprise. Until the Internet, desktop security wasn't an issue for anybody except businesses, and that's why they used NT.
Over those years many, many, many applications were written for those flavors of Windows. These applications all assumed they were running as admin, and for good reason... they were! It wasn't until just 5 years ago that Microsoft finally made the push to get consumers on to the NT kernel, with all its nice security features and the new world of multiple users with varying permissions. Ut oh. There in lies the problem. Microsoft couldn't simply make users non-admin by default because now almost all existing desktop applications, the very thing people buy Windows for in the first place, would break.
So Microsoft had to make a hard choice... break all existing applications and go out of business, or have the users run as admin by default. Tough choice.
Admittedly, Microsoft should have done a MUCH better job over the past 5 years to get people to develop Windows applications the correct way. Aside from their "Logo Certification", they've done almost nothing.
Vista's UAC is a huge step forward for Windows, and it solves a very difficult technical problem that is absolutely unique to Windows: a massive legacy software library dating back 20+ years that *must* run flawlessly on every new version of Windows. Microsoft does not have the luxury of breaking every existing application like Apple does (thanks to their extremely small, yet insanely loyal user base), nor do they have the pleasure of having a software library written with multi-user systems in mind from the get-go, like Unix/Linux.
Cleary this isn't as simple as Microsoft being "fraudulent", nor is it "marketing bullshit", and they certainly have never claimed it wasn't a problem.
As you can see, the adage in question is perfectly reasonable and applies to everybody, not just Windows users.
I'm not sure that's true (I think I remember hearing about an x64 proof of concept root kit), but even if that is true it's just because the layout of OS components in memory has changed.
Getting around this is simply a matter of coding for it.
The Address Space Randomization, however, would make this very, very hard.
Sorry, that first link should be:
:(
Address space randomization.
Helps if you actually preview before posting.
I think it's somewhat disingenuous to specifically note this rootkit works in Vista. It implies that the security work done in Vista has somehow failed.
Vista has numerous improvements security wise, and almost all of them have to do with prevent a machine from becoming infected to begin with.
, UAC, Windows Defender, the improved software firewall, IE 7+ sandboxing/broker, etc... these are all meant to make it a lot harder for malware to get on the machine to begin with.
As the old security adage goes, if untrusted software is run on your machine, it's not your machine anymore.
I don't know if developers are taking advantage of it, or to what extent it supports it, but I'm fairly sure the Xbox 360 already has Procedural Synthesis capabilities.
These are all excellent books.
http://www.amazon.com/gp/product/0735619034/ (ASP.NET 1.x)
http://www.amazon.com/gp/product/0201760401/ (ASP.NET 1.x)
http://www.amazon.com/gp/product/0735621764/ (ASP.NET 2.x)
http://www.amazon.com/gp/product/0735621772/ (ASP.NET 2.x)
I added a little... plus, my nick is the same on both sites, so I'm not trying to hide anything! :)
:)
I figure if Slashdot can steal stories from Digg, I can copy my responses back and forth in the forums.
Ya, I wouldn't want to pay that either. Luckily, Windows doesn't cost that much money.
u y/licensing/pricing.mspx
Windows Server 2003 Web Edition, 32-bit version - $399 Open NL
Windows Server 2003 R2 Standard Edition - $999 (5 CALS)
Windows Server 2003 R2 Standard Edition - $1,199 (10 CALS)
Windows Server 2003 R2 Enterprise Edition - $3,999 (25 CALS)
http://www.microsoft.com/windowsserver2003/howtob
You can also get licenses for a lot less than retail on eBay, and it's perfectly legal. I've purchased Web Edition for as little as $200, and Enterprise for $1200. There are lots of companies who buy these things in bulk and end up not using them.
In addition, if you're not hosting an external site (customer facing) you can get an Action Pack subscription for about $300 that gives you access to up to 5 licenses for each of these OS's.
See: https://partner.microsoft.com/40016470
I agree. In fact, I'm a fan of a lot of Microsoft stuff. (*ducks*) I've developed systems that were blazing fast and were written with .NET.
I'm just saying that, in this case, the benchmark is completely useless. It would be like conducting a drug trial to determine if a particular drug works, but letting the participants also take any other drugs they want in addition to smoking some crack on the weekends.