Scada Moosh writes "ZDNet has a story about the lessons Microsoft learned from the recent animated cursor (.ani) attacks and some of the broad changes being made to flag this type of vulnerability ahead of time. The changes include a possible addition to the list of banned API function calls, more aggressive checks for buffer overruns and enhancements to existing fuzz testing tools. '[Michael] Howard said Microsoft will "rethink the heuristics" used by the /GS compiler to flag certain issues. "Changing the compiler is a long-term task. In the short-term, we have a new compiler pragma that forces the compiler to be much more aggressive, and we will start using this pragma on new code," he added. Two other Windows Vista security mechanisms -- ASLR and SafeSEH -- were also in place to catch code failures but, in the case of the .ani bug, Howard said the attackers were able to wrap vulnerable code in an exception handler to find ways around those mitigations.'"
Does the banning of an API call mean that the call is still there, it just can't be officially used? Couldn't it still be used deviously to exploit it? Shouldn't we just remove the function from the API, not prevent the compiler from compiling code with that function being used?
Take a gander at Microsoft's list [microsoft.com]. If the Safe options are on, the API is not available.
It's all kinds of sexy... but basically, it removes functions in which programmers have frequently used incorrect or for which there is no absolutely correct way to use them and still validate user supplied data.
A banned API is one that is likely to cause security vulnerabilities. There are replacements for most of them that are less likely to have problems, but they aren't part of the official C standard library. Microsoft's build tools will treat any calls to banned APIs [microsoft.com] as errors. They aren't removed from the system because they are used by many existing applications. For example, both strcpy and strncpy are banned at Microsoft. Yet many people have been using strncpy as a replacement for strcpy, so it needs to b
Probably because instead of the banned strncpy Microsoft are using strcpyEx, which includes an extra parameter "iAllowDeny". When set to 1, this prevents buffer overflows. But because of the unfortunate name, some programmers think it will 'allow' exploits so they set it to 0.
If only Microsoft would add a C++lippy to MSVC to clear up these kinds of things.
You appear to be writing a buffer overflow. Would you like to:
1. Switch to a certified safe string copy function? 2. Cause Vista to pop up a security dialog every time your function is run? 3. See more information on currently unpatched Windows exploits? 4. See tips on how to acquire fame and fortune as a virus writer?
While risking being out of sync with Slashdot's schizophrenic stance on Microsoft-bashing, let me lower my hammer on this one:
"The changes include a possible addition to the list of banned API function calls"
That's exactly the problem with security under Windows! (okay, there are other problems as well)
Microsoft needs to apply a "default deny" policy to all aspects of Windows' security and this sort of thing wouldn't be a problem in the first place. There shouldn't be a list of BANNED calls, there should be a list of safe ALLOWED calls.
I'm not saying that other operating systems couldn't do a better job too, but security is one (huge) area where Microsoft really and truly sucks - and it isn't something they can solve overnight, either. It seems ingrained in their philosophy and permeates all aspects of Windows (and other products).
Actually what they need to do is get rid of all that legacy crap code they have that assumes everyone on the internet is a good friend. "Banning" APIs and coming up with workarounds to fundamental design problems (seriously, an animated cursor??) is simply piling band-aids on top of each other until they forget which one did what.
Unfortunately for Microsoft, they have a hell of a lot of that sort of code in Windows and a lot of their products. The ones they've really re-engineered like IIS6 or written fro
There shouldn't be a list of BANNED calls, there should be a list of safe ALLOWED calls.
I think this is similar to the GCC concept of hiding symbols. The only real issue is when compiling legacy code which links directly to those hidden symbols, linking will fail. Obviously, that's the point. I think, then, that the Microsoft approach is lazy: they're more worried about "legitimate" legacy code no longer working well with later compilers than they are about actually hiding the offending API calls from userspace all together.
I'm not saying that other operating systems couldn't do a better job too, but security is one (huge) area where Microsoft really and truly sucks - and it isn't something they can solve overnight, either. It seems ingrained in their philosophy and permeates all aspects of Windows (and other products).
It's the PC heritage, going back to the days when no-one in the non-Unix PC world gave the slightest thought to security, because you could get away with it back then. It's a difficult mindset to change, beca
Perhaps "PC heritage" was the wrong term. I was really thinking "microcomputer heritage", going back to the days of the S-100 bus, Apple, and the countless other pre-PC machines. That was before hard disks were common, let alone LANs, and macro viruses were not an issue until much later. Many of the people involved at that time were busy reinventing things from scratch, starting at the most rudimentary level. They mostly ignored any lessons that might have been had from software on bigger iron, because
The problem with getting your information about Vista from Apple's propoganda is that when you're trying to evangelise to Windows users, they realise that what you're saying is crap, and ignore you -- even if whatever you're evangelising is genuinely more secure than what they're using (which it obviously definitely is with Linux as compared to Windows).
Old Bill's Livery and Horse Trading post announced that they have decided to strengthen the windows of the stable because horses were being stolen with surprising regularity. When the reporters queried the wisdom of strengthening the windows while the door is wide open and unlocked, Old Bill's assistant Steve threw the straw bales he was sitting on at the reporters.
The main problem is that complex software is just hard to secure. And not just complex MS software - they are not the only ones suffering these kinds of vulnerabilities.
This incremental approach will eventually result in operating systems that are secure to all but the most sophisticated local attacks. You can't stop the attack where someone just downloads something and blindly runs it. Unlike most people, I don't think computer OS's and apps will always be as insecure as they have been for the last 15 years since the explosion of the Internet to the masses.
It may take another 5 years, but I think we're getting there. Vista isn't perfect, but it's a step closer.
This incremental approach will eventually result in operating systems that are secure to all but the most sophisticated local attacks.
And since those attacks are For Sale for $3000 to $5000 on the Internet, everyone with intent to do serious, widespread damage will still be using them.
Linux, Mac, Solaris all have servers user features M$ is still trying to catch up to but none of the problems.
I thought I remembered a specific Solaris telnet exploit [slashdot.org] not too long ago that was incredible oversight by Sun. I guess that must have really been a Microsoft telnet daemon?
Normally I'd argue, but it would be like arguing with a retard over whether the moon is made of cheese or not. You say a bunch of things, but you're just blathering a bunch of fat, geeky dweeb nonsense.
Fortunately people like you who are incapable of adapting to new technology and get emotional about operating systems get weeded out. Face it, brother, you're a dinosaur.
The changes include a possible addition to the list of banned API function calls, more aggressive checks for buffer overruns and enhancements to existing fuzz testing tools.
You know if Bill Gates was any kind of leader, he would call for his programmers to scrutinize their code for these kinds of security issues. Oh wait! He did 5 years ago. [usatoday.com] It's great to know that MS has spent the last 5 years innovating such features.
...Is re-evaluate what the true purpose of the operating system is, and stick to it instead of tacking so much nonsense to the abomination that today we call Windows.
Microsoft made a big to-do about "focusing on security" in the development of Windows Vista, but instead spent all this time A) spackling over the screwball security holes that the superfluous bits of the last version of the operating system created, and B) bolting on more superfluous bullshit.
The pattern of flagrant Windows/Microsoft security breaches has traditionally involved the fracal-like fuzz of superfluous features surrounding Windows. It simply tries to be too much. How many times have we heard about some hole in Internet Explorer that lets l33t h4xx0rs walk in and screw with your OS? Animated cursors opening security holes. ET-phone-home Windows Media player opening security holes. IIS subsystems on home user's computers opening security holes... Ad infinitum.
You want a web browser on your PC? Install a web browser. It shouldn't be your OS'es job. You want animated cursors? Install a cursor manager. It shouldn't be the OS'es job. You want media players? Install a media player. It shouldn't be the OS'es job. Are we seeing the fucking pattern here, yet? If Microsoft could focus on the core of the operating system, making it the platform and the framework that the rest of your computing experience happens on instead of trying to make it the damn "multimedia/computing experience" itself I'll wager a significant portion of these stupid, smack-on-the-forehead sort of problems would go away. And if and when they did crop up, users affected could just patch or uninstall the affected browser/media player/cursor manager/whatever instead of having it permanently tied into their OS for the rest of time (heaven forbid, for example, users reinstalling Windows into it's stock, unpatched state).
In theory, your idea would work well. You would install an OS and a command shell from a vendor and get everything else from somewhere else. That's what DOS and early Linux distros were like. However, a key piece to overall system stability is integration testing. Debian does TONS of integration testing. Hence, stable is stable. The problem with leaving the integration testing to the user is that you turn a simple "poke-me" appliance into one of those annoying machines that geeks are always tinkering with. T
The truth is that Vista is a home user OS. It was designed to play games and show movies. It was not designed to be used in a business, or to be used for any serious purpose beyond playing Donkey Kong and watching Mickey Mouse cartoons...
Not really. When the MS first brought in Windows NT, it was solely a business OS -- home users had 3.1/9x. It's only since WIndows XP that the consumer line has used the NT codebase as well (Vista is NT 6.0).
Howard said the attackers were able to wrap vulnerable code in an exception handler to find ways around those mitigations.
This is incorrect.
Howard said that the vulnerable code happened to be wrapped in a very general try/catch block.
This try/catch block, which was in the vulnerable code already, and not injected by the attackers, potentially allowed the attackers to repeatedly try different memory locations looking for system call addresses that were randomized by ASLR.
Without this try/catch, the process would have crashed after the first failed attempt.
In other words, liberal try/catch policies can potentially expose security vulnerabilities by giving bad guys more than one chance to do their bad deeds.
Also, there were no reported instances of Vista being compromised. It is doubtful that the engineers of the various exploits targeted Vista, and therefor didn't take advantage of the try/catch issue to overcome ASLR since XP doesn't have ASLR. In addition, Protected Mode IE would have thwarted the attack even if they had.
Wasn't Vista rewritten from scratch, rather than using the old NT code base? Isn't this wh it took an extra 3 years to arrive? Isn't this where there are still major compatibility errors in Vista compared to previous NT and Win95/98/ME versions?
So what did they do here? Rewrite the.ANI handler by re-implementing the same bug as before?
I think that was the original intention, but my interpretation of events is that they found that.NET wasn't up to snuff, and rather than eat their own dog food but deliver a crappier product they did the 'Vista reset'. After the reset they re-used much of the code from XP.
.NET wasn't up to snuff? Find me a single article that says anything even remotely like this.
The Vista reset was caused by a flawed attempt to include too many features at once combined with unsustainable development practices / management. It had absolutely nothing to do with.NET. Not to mention the fact that Vista is based off of the Windows 2003 Server codebase, not XP's.
Furthermore, there was never a plan to rewrite Windows from the ground up.
After the reset they re-used much of the code from XP.
Wrong way round. As VertigoAce notes [slashdot.org], it was the pre-reset builds which were based of XP; the post-reset ones were based on 2003 Server.
They used to do it regularly. NT stood for "New Technology."
NT 3.0 was written from scratch. Please provide proof to the contrary, if you have it. Then, provide proof that *Microsoft* has claimed Vista is rewritten from scratch. And I said Vista, not Longhorn or anything else.
I can't tell you how many times they declared the "death of DOS"
I'd calculate that about the same number of times you've declared "M$ Winblows" was "dead".
The wikipedia entry, which they pay people to write, claims, "hundreds of new features; some of the most significant include an updated graphical user interface and visual style dubbed Windows Aero, improved searching features, new multimedia creation tools such as Windows DVD Maker, and completely redesigned networking, audio, print, and display sub-systems." In short new everything, which clearly is not true
Ummm, no. You seem to have a serious misconception about what exactly an operating system is. Multimedia features, searching features, even networking, audio print etc. subsystems do not an OS make. The kernal is still the NT kernel -- with some changes, but still broadly the same -- which is why Vista is NT 6.0. No-one at Microsoft has ever claimed otherwise; no Wikipedia editor has ever claimed otherwise.
Both of them lead the reader to believe that Vista, has replaced everything of importance to the user.
I've just had a look at the Wikipedia pages again. They list, in quite some detail, exactly what has been changed and what is new, both on the surface [wikipedia.org] and underneath [wikipedia.org]. Is there anything there (most notably in the latter page, which describes the kernel & core OS changes) that you believe to be false? If so, and you have evidence, change the page and cite it, it is a Wiki. Even if there's just something on the page that you think goes beyond the remit of the sources there, raise it in the talk page o
Proof, flocktard. You were asked [slashdot.org] for proof. Semantic nitpicking of your own posts doesn't count. Prove that the contents of that WP entry are provided by "M$". Go ahead, we're all waiting. Just like those inexistent Linux botnets, the lawsuits that "destroyed" the Zaurus, your "job" at a "Fortune 100" company and all our other FUD.
It was delayed largely because they reset the project in late 2004. The original Longhorn was based off of the XP codebase. When they reset development they started from the Windows 2003 codebase (which was based off of the XP codebase). At no point did they claim that they were starting from scratch. Many of the compatibility problems are related to fixing bugs in the OS. Any time you change the behavior of the operating system you risk breaking some piece of code that relied on the old behavior. Notice tha
I still can't get over why generating "safe" code is the job of the compiler, anyway. What's wrong with checking lengths and buffers before using them? What's wrong with paranoid programming?
Did Microsoft's new focus on security from the ground up with Vista really just amount to compiling all its system components with/GS? Pathetic.
Prior to Vista, you could drag files from Explorer to cmd.exe to have it type in the filename for you, exactly like on Mac. However, due to overzealous security changes by Microsoft, this does not work in Vista [microsoft.com].
In NT, console windows are actually owned by the most privileged user-mode process in the system, csrss.exe. One of Vista's big security changes is that processes cannot send window messages to windows owned by processes of higher security clearance. This means that Explorer cannot send a message to console windows telling them that there is a file being dragged to it. Starting Explorer as Administrator does not help, because csrss.exe runs with higher privilege than that.
Rather than fix the insane design issue of csrss.exe owning console windows, they decided to leave it the way it is. Never mind that there have been exploits against csrss.exe through the console system in the past.
To give you an idea of how bad of a hack the console implementation is, kernel32.dll's WriteFile detects console handles, which are fake handles, and translates the call into an RPC call to csrss.exe. This breaks all kinds of stuff.
Hire people who know that it's a really, really, really bad idea to drop a structure onto the stack, especially if said structure is to be filled by user data. That should take care of the issue. Instead of fixing the underlying problem, MS tries hard to "fix" the world around it. It's not an issue with the compiler, it's not an issue with API calls that can be "abused", it's an issue with badly written API functions. Grab the source of those friggin' libs and move the structures that you moronically created
Please explain to me how it's going to get into my "BIOS" with Vista-specific flaws, and then we'll chat. You can use all the dollar signs you want, but do me a favor and try to make at least a bit of sense.
But no, what your AC sock puppets have claimed is not true - this won't work on gnu/linux. It only works for Vista by exploiting M$ specific flaws. Those flaws were originally designed to lock you out of your kernel and it looks like they have done exactly that.
Umm, no. Rootkits existed for Windows long before Vista and kernel patch protection. Rootkits exist for Linux. Rootkits exist for MacOS. Newsflash: if you compromise a system at the kernel level, your system is -- wait for it -- compromised. Obviously.
Show me the gnu/linux demonstration and I might believe you.
Google is your friend. A quick Google gives: SucKIT, Rial, heroin, afhrm, Synapsis, adore, knark, itf, kis as some exanples. That's almost certainly not a comprehensive list, and I've no idea whether it's current. And, of course I'm certainly not say
I've no idea when Linus is going to release 2.0.24, but if he takes
too long Im going to release a 2.0.24unoff and he can sound off all
he likes.
-- Alan Cox
What is a banned API call? (Score:5, Interesting)
Re: (Score:2)
Re:What is a banned API call? (Score:4, Informative)
It's all kinds of sexy... but basically, it removes functions in which programmers have frequently used incorrect or for which there is no absolutely correct way to use them and still validate user supplied data.
Parent
Re: (Score:3, Informative)
Microsoft's build tools will treat any calls to banned APIs [microsoft.com] as errors. They aren't removed from the system because they are used by many existing applications. For example, both strcpy and strncpy are banned at Microsoft. Yet many people have been using strncpy as a replacement for strcpy, so it needs to b
Re: (Score:2)
Kind of makes you wonder why there are so many buffer overflows in Windows, doesn't it?
Re: (Score:3, Funny)
If only Microsoft would add a C++lippy to MSVC to clear up these kinds of things.
Re: (Score:2)
You appear to be writing a buffer overflow. Would you like to:
1. Switch to a certified safe string copy function?
2. Cause Vista to pop up a security dialog every time your function is run?
3. See more information on currently unpatched Windows exploits?
4. See tips on how to acquire fame and fortune as a virus writer?
Default deny policy (Score:3, Insightful)
While risking being out of sync with Slashdot's schizophrenic stance on Microsoft-bashing, let me lower my hammer on this one:
"The changes include a possible addition to the list of banned API function calls"
That's exactly the problem with security under Windows! (okay, there are other problems as well)
Microsoft needs to apply a "default deny" policy to all aspects of Windows' security and this sort of thing wouldn't be a problem in the first place. There shouldn't be a list of BANNED calls, there should be a list of safe ALLOWED calls.
I'm not saying that other operating systems couldn't do a better job too, but security is one (huge) area where Microsoft really and truly sucks - and it isn't something they can solve overnight, either. It seems ingrained in their philosophy and permeates all aspects of Windows (and other products).
Re: (Score:2)
Unfortunately for Microsoft, they have a hell of a lot of that sort of code in Windows and a lot of their products. The ones they've really re-engineered like IIS6 or written fro
Re: (Score:2)
There shouldn't be a list of BANNED calls, there should be a list of safe ALLOWED calls.
I think this is similar to the GCC concept of hiding symbols. The only real issue is when compiling legacy code which links directly to those hidden symbols, linking will fail. Obviously, that's the point. I think, then, that the Microsoft approach is lazy: they're more worried about "legitimate" legacy code no longer working well with later compilers than they are about actually hiding the offending API calls from userspace all together.
Re: (Score:2)
It's the PC heritage, going back to the days when no-one in the non-Unix PC world gave the slightest thought to security, because you could get away with it back then. It's a difficult mindset to change, beca
Re: (Score:2)
Re: (Score:2)
"Allow or deny?"
Windows security is a sad joke. Unfortunately few people realize that.
Re: (Score:2)
("What triggers a UAC prompt" [edbott.com]
Related news (Score:5, Funny)
In context (Score:2)
Incremental approach. (Score:4, Insightful)
This incremental approach will eventually result in operating systems that are secure to all but the most sophisticated local attacks. You can't stop the attack where someone just downloads something and blindly runs it. Unlike most people, I don't think computer OS's and apps will always be as insecure as they have been for the last 15 years since the explosion of the Internet to the masses.
It may take another 5 years, but I think we're getting there. Vista isn't perfect, but it's a step closer.
Re:Incremental approach. NOT ANY SAFER (Score:2)
And since those attacks are For Sale for $3000 to $5000 on the Internet, everyone with intent to do serious, widespread damage will still be using them.
Re: (Score:2)
I thought I remembered a specific Solaris telnet exploit [slashdot.org] not too long ago that was incredible oversight by Sun. I guess that must have really been a Microsoft telnet daemon?
So? (Score:2)
I thought I remembered a specific Solaris telnet exploit not too long ago that was incredible oversight by Sun.
You win! I give up and admit the equality of Solaris and Windoze security models. Swarms of Sun powered bots will soon take down the internet.
Re: (Score:2)
Fortunately people like you who are incapable of adapting to new technology and get emotional about operating systems get weeded out. Face it, brother, you're a dinosaur.
For starters.... (Score:3, Insightful)
Wait, sounds familiar (Score:2)
You know if Bill Gates was any kind of leader, he would call for his programmers to scrutinize their code for these kinds of security issues. Oh wait! He did 5 years ago. [usatoday.com] It's great to know that MS has spent the last 5 years innovating such features.
Use non-overflowing buffers, heaps etc. (Score:2)
In this day and age of OOP and libraries, there's no excuse but negligence for crappy code.
Windows - be careful! (Score:3, Funny)
What Microsoft REALLY Needs To Do... (Score:3, Insightful)
Microsoft made a big to-do about "focusing on security" in the development of Windows Vista, but instead spent all this time A) spackling over the screwball security holes that the superfluous bits of the last version of the operating system created, and B) bolting on more superfluous bullshit.
The pattern of flagrant Windows/Microsoft security breaches has traditionally involved the fracal-like fuzz of superfluous features surrounding Windows. It simply tries to be too much. How many times have we heard about some hole in Internet Explorer that lets l33t h4xx0rs walk in and screw with your OS? Animated cursors opening security holes. ET-phone-home Windows Media player opening security holes. IIS subsystems on home user's computers opening security holes... Ad infinitum.
You want a web browser on your PC? Install a web browser. It shouldn't be your OS'es job. You want animated cursors? Install a cursor manager. It shouldn't be the OS'es job. You want media players? Install a media player. It shouldn't be the OS'es job. Are we seeing the fucking pattern here, yet? If Microsoft could focus on the core of the operating system, making it the platform and the framework that the rest of your computing experience happens on instead of trying to make it the damn "multimedia/computing experience" itself I'll wager a significant portion of these stupid, smack-on-the-forehead sort of problems would go away. And if and when they did crop up, users affected could just patch or uninstall the affected browser/media player/cursor manager/whatever instead of having it permanently tied into their OS for the rest of time (heaven forbid, for example, users reinstalling Windows into it's stock, unpatched state).
Re: (Score:2)
However, a key piece to overall system stability is integration testing. Debian does TONS of integration testing. Hence, stable is stable. The problem with leaving the integration testing to the user is that you turn a simple "poke-me" appliance into one of those annoying machines that geeks are always tinkering with. T
Re: (Score:2)
Re: (Score:2)
Innaccurate Summary (Score:3, Insightful)
Howard said that the vulnerable code happened to be wrapped in a very general try/catch block.
This try/catch block, which was in the vulnerable code already, and not injected by the attackers, potentially allowed the attackers to repeatedly try different memory locations looking for system call addresses that were randomized by ASLR.
Without this try/catch, the process would have crashed after the first failed attempt.
In other words, liberal try/catch policies can potentially expose security vulnerabilities by giving bad guys more than one chance to do their bad deeds.
Also, there were no reported instances of Vista being compromised. It is doubtful that the engineers of the various exploits targeted Vista, and therefor didn't take advantage of the try/catch issue to overcome ASLR since XP doesn't have ASLR. In addition, Protected Mode IE would have thwarted the attack even if they had.
But I Thought... (Score:3, Interesting)
So what did they do here? Rewrite the .ANI handler by re-implementing the same bug as before?
Or were we just lied to again, by Microsoft?
Re:But I Thought... (Score:5, Informative)
I guess it's easy to be mad at Microsoft for lying when you put those lies in their mouth yourself.
Parent
Re: (Score:3, Informative)
Re: (Score:2)
The Vista reset was caused by a flawed attempt to include too many features at once combined with unsustainable development practices / management. It had absolutely nothing to do with
Furthermore, there was never a plan to rewrite Windows from the ground up.
Informative, indeed.
Re: (Score:2)
Re:When have they stopped saying that kind of thin (Score:3, Insightful)
NT 3.0 was written from scratch. Please provide proof to the contrary, if you have it. Then, provide proof that *Microsoft* has claimed Vista is rewritten from scratch. And I said Vista, not Longhorn or anything else.
I'd calculate that about the same number of times you've declared "M$ Winblows" was "dead".
But I could be wrong.
Please provide proo
Re: (Score:2)
The wikipedia entry, which they pay people to write, claims, "hundreds of new features; some of the most significant include an updated graphical user interface and visual style dubbed Windows Aero, improved searching features, new multimedia creation tools such as Windows DVD Maker, and completely redesigned networking, audio, print, and display sub-systems." In short new everything, which clearly is not true
Ummm, no. You seem to have a serious misconception about what exactly an operating system is. Multimedia features, searching features, even networking, audio print etc. subsystems do not an OS make. The kernal is still the NT kernel -- with some changes, but still broadly the same -- which is why Vista is NT 6.0. No-one at Microsoft has ever claimed otherwise; no Wikipedia editor has ever claimed otherwise.
Re: (Score:2)
Both of them lead the reader to believe that Vista, has replaced everything of importance to the user.
I've just had a look at the Wikipedia pages again. They list, in quite some detail, exactly what has been changed and what is new, both on the surface [wikipedia.org] and underneath [wikipedia.org]. Is there anything there (most notably in the latter page, which describes the kernel & core OS changes) that you believe to be false? If so, and you have evidence, change the page and cite it, it is a Wiki. Even if there's just something on the page that you think goes beyond the remit of the sources there, raise it in the talk page o
Proof (Score:2)
Re: (Score:3, Informative)
Many of the compatibility problems are related to fixing bugs in the OS. Any time you change the behavior of the operating system you risk breaking some piece of code that relied on the old behavior. Notice tha
Compiler issue? (Score:2)
Did Microsoft's new focus on security from the ground up with Vista really just amount to compiling all its system components with
Security broke dragging files to cmd.exe (Score:5, Interesting)
In NT, console windows are actually owned by the most privileged user-mode process in the system, csrss.exe. One of Vista's big security changes is that processes cannot send window messages to windows owned by processes of higher security clearance. This means that Explorer cannot send a message to console windows telling them that there is a file being dragged to it. Starting Explorer as Administrator does not help, because csrss.exe runs with higher privilege than that.
Rather than fix the insane design issue of csrss.exe owning console windows, they decided to leave it the way it is. Never mind that there have been exploits against csrss.exe through the console system in the past.
To give you an idea of how bad of a hack the console implementation is, kernel32.dll's WriteFile detects console handles, which are fake handles, and translates the call into an RPC call to csrss.exe. This breaks all kinds of stuff.
backwards (Score:2, Interesting)
Another pointless discussion that doesn't acknowledge the depth of complexity of backwards compatability, and its commercial necessity.
Easy fix (Score:2)
Instead of fixing the underlying problem, MS tries hard to "fix" the world around it. It's not an issue with the compiler, it's not an issue with API calls that can be "abused", it's an issue with badly written API functions. Grab the source of those friggin' libs and move the structures that you moronically created
Re:Maybe... (Score:4, Funny)
Parent
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
But no, what your AC sock puppets have claimed is not true - this won't work on gnu/linux. It only works for Vista by exploiting M$ specific flaws. Those flaws were originally designed to lock you out of your kernel and it looks like they have done exactly that.
Umm, no. Rootkits existed for Windows long before Vista and kernel patch protection. Rootkits exist for Linux. Rootkits exist for MacOS. Newsflash: if you compromise a system at the kernel level, your system is -- wait for it -- compromised. Obviously.
Show me the gnu/linux demonstration and I might believe you.
Google is your friend. A quick Google gives: SucKIT, Rial, heroin, afhrm, Synapsis, adore, knark, itf, kis as some exanples. That's almost certainly not a comprehensive list, and I've no idea whether it's current. And, of course I'm certainly not say
Re: (Score:2, Troll)
Thanks, I'm not half as organized with my Slashdoting as you are!