Ok, I just read most of the actual white paper (http://taossa.com/archive/bh08sotirovdowd.pdf) and this technique requires:
1.) A browser exploit that allows for a buffer overflow.
2.) A.NET control or Java applet loaded into the browser's memory whose PE header has been modified to include the malicious shell code.
Given these two things (only the 2nd of which is actually a given), you would still be constrained by Protected Mode in IE. In other words, the best you could do would be to crash the browser and maybe generate an error dialog of some sort.
If, however, the exploit was in a component that used a broker class to facility communications with a browser plugin, and that broker class was running as the current user, then you could at least access that user's files/data. If the broker class was running as system (which none do), you could take over the machine.
Flash is an example of a BAD, BAD plugin that has a broker class which could be used to facilitate an attack like this.
But let me reiterate that you first need an exploit, and that exploit must be one in an existing browser plugin (basically just Flash) that has a brokering mechanism that bypasses Protected Mode.
Without that, this doesn't do jack. Really, this is just a reliable way to defeat DEP/ASLR. Nothing more. It just makes the Flash exploit used in the hacking contest a few months back a bit more interesting. That exploit has since been patched, btw.
Except that a large number of the features in Cairo made it into various Microsoft products over the years.
And that's kind of the point of a research product... to come up with ideas, see if they work, and then incorporate them into commercial products where it makes sense.
Thanks for laying that out. I do understand what Microsoft is trying to do with Midori.
I didn't talk about these aspects of the project because I wasn't trying to explain Midori as a whole, just that Slashdot's article summary was stupid.
I don't think that these things ever were synonymous with being web-based.
The web is the World Wide Web. It's that thing you look at view a web browser. It uses HTTP as its primary protocol. It's connectionless. It's meant primarily as a mechanism for viewing content, although it has been co-opted as an application communications mechanism due to its simplicity, ubiquitousness, and easy of development.
None of these things has anything to do with the design of Midori.
Midori will *not* be "web based", whatever the hell that means.
Being "internet centric" and connected to "the cloud" is not the same has being web based.
Midori is being designed in such a way that components of the OS communicate with each other in a location independent manner. API calls to a local machine are no different than API calls to a remote machine. These calls will also be "message based" (there are lots of ways to interpret that) and be transactional in nature.
Above these kinds of low level things, there will be a much tighter and more integrated connection to the network. Your profile will roam with you no matter where you are using P2P style communications similar to how Live Mesh works, although supported by core OS components instead of via RSS synchronization.
So if your idea of a "web based" OS is like what I've described above, then yes... it's web based.
But if you're thinking about a subscription-based model where a user must boot their OS "from the web" like a dumb terminal, then you're way off.
Lastly, this thing is at least 7 to 10 years off. Windows 7 will ship sometime next year (or perhaps early in 2010), and Midori isn't even out of MS Research yet. If we saw something like this before Windows 8 / 2015, I'd be damn surprised.
I do think that convicting somebody based on circumstantial evidence is almost always a bad idea. In fact, it's such a bad idea, it usually doesn't happen... and when it does, the judge often steps in and overturns the conviction.
In this case, you have a guy who did some things that are pretty damn hard to explain away. The day after his wife goes missing he removes the passenger seat from his car and hoses the entire thing down? Seriously?
Should that be enough to convict him? I don't know. What I do know is that I find it very strange that so many of you are willing to ignore things like that and declare your outrage about his conviction.
Now that he has been found guilty, perhaps you should explain why you think he is innocent?
It's funny, this problem was just being discussed on the SGU forums. It happened to be given as a puzzle on a recent SGU podcast, before the NYT story was run.
Anyway, here is the simple explanation that I've found helps people realize their error in thinking:
The problem is a lot easier if you think about it in an "outcome" based fashion.
In other words, what are the three possible outcomes given that the person always switches their door?
[car] [goat] [goat]
Choose door 1. Host reveals door 3. Switch to door 2. NO CAR.
Choose door 2. Host reveals door 3. Switch to door 1. CAR.
Choose door 3. Host reveals door 2. Switch to door 1. CAR.
What are the three results? NO CAR, CAR, and CAR. In other words, always switching your answer results in a 2/3 chance of getting a car.
If we repeat this process but we never switch our door, you get:
Choose door 1. Host reveals door 3. No switch. CAR.
Choose door 2. Host reveals door 3. No switch. NO CAR.
Choose door 3. Host reveals door 2. No switch. NO CAR.
Now we only have a 1 in 3 chance of getting the car.
My blog posts are not wrong. There is a difference between graphical SUDO / the Mac OS X authorization prompt, and Vista's UAC.
The biggest difference is that Vista's UAC prompt is automated. Any attempt at doing something that requires admin access automatically results in a UAC prompt.
This is not what happens on Mac OS, and it is not what happens on Linux. In the case of Mac OS, their authorization prompt basically only appears when the user does things in the control panel, installs certain apps, or does file operations on locations they don't have access to.
In the case of Linux, most tasks that require admin access will just fail out right if you aren't running as su/root.
In both scenarios, the prompts only happen when they've been specifically coded for by the OS or application. This is fine, since the vast majority of applications written for these environments know this, and are designed with this in mind. Legacy software that doesn't play by the rules isn't an issue.
This is not the case with Windows. On Vista, a UAC prompt will happen any time any process attempts to do something that requires admin access but is not running as admin. If a crappy/legacy app calls to an API, or tries to write to a file, or whatever, and this action requires admin access, a UAC prompt automatically appears. In addition, when running as "admin" on Vista you're not really an admin (it only changes the UAC prompt so that not username/password is required).
Why would Microsoft do this if there weren't a huge body of legacy software that would simply break if it was not running as admin? It is a *fact* that UAC is a compatibility mechanism... Microsoft has repeated stated this. Not only that, but a huge part of UAC is heuristic based... so it can detect the potential for requiring admin access ahead of time. This is particularly useful with installers, control panel apps (.cpl), etc.
Sure the APIs have been there to play nice with NT-style permissions / user isolation... but Microsoft was horrible at enforcing that, even with XP. Lazy ISVs continued to do it the old way because it worked. The fact it was possible to do it the right way, or that you could "Run As Admin" has absolutely no bearing on this discussion.
No. The fact that they specifically stated the exploit was in Flash suggests the exploit, or exploit vector, was in Flash. Everything else you mention is purely assumption. That makes no sense. The people who write these exploits aren't stupid. They aren't going to target an attack vector that has multiple layers of protection unless they've already figured out ways around that protection. Targeting a buffer overflow in an application running with low privs would be useless unless you've already figured out a way to elevated the privileges of that user.
These are not assumptions. These are facts. If the team that performed the hack found multiple exploits, they would have stated as much. For you to say they would not have is ridiculous. In fact, it was part of the rules that they explain exactly how the hack was performed.
Windows is still carrying the baggage of a single-user system and as long as that is the case it will be easier to exploit. Huh? What does this have to do with the baggage of Windows' history? Seems to me that you are the one making assumptions.
UAC does raise the barrier, but addresses a problem that only exists on Windows, since that OS still does not properly compartmentalize users the way other OSs do. You do realize that this has nothing to do with UAC, right? The file in question was accessible by the user running the browser. It didn't require admin privs. Protected Mode and UAC are two entirely different things. I'll assume, for the moment, that you're no longer talking about Protected Mode, IE, and this exploit and instead have switched topics to my blog posts regarding Windows' history and why UAC is necessary.
You obviously didn't understand my blog posts because UAC being necessary has nothing to do with any deficiencies in Windows with regards to the ability to "compartmentalize users". The fundamental security model behind Windows is every bit as capable (and, indeed, more advanced in may ways) as Linux. The problem is that there were two distinct branches of Windows: NT and 9x. When these two branches were merged, it was absolutely necessary to ensure that the 9x software ran on the NT-based versions of Windows.
As I mentioned in my blog post in great detail, it was this support for legacy software that resulted in Windows defaulting to admin on XP, and eventually to Vista needing UAC. UAC is, for the most part, a compatibility mechanism, not a security boundary.
In fact, the only big difference between UAC and the way the Mac handles this is that the Mac doesn't have any mechanism to automatically detect admin operations... so if an application tries to perform an action that requires admin privs, and it doesn't have them, it will just fail. On Vista, it will prompt the user. The same goes for Linux. Applications trying to perform admin operations that don't have perms will just fail and error out. Can you see why that would be an issue on an OS with literally millions of software titles that assume admin access?
My own logic is sound. But I suggest that next time you feel like discussing such things, you rely on facts and leave assumptions at the door. No, your logic is not sound. It is clear to me, and probably most other people reading these comments, that it is you making assumptions.
I was not aware that Flash did this. This would certain explain how it was possible without resorting to using Firefox, or some other browser, as the host for Flash.
Can you post some documentation that details this? It must be new for the Vista/IE version of Flash, since I can't think of any reason why they would have done this pre-Vista.
I never suggested that they turned off UAC or Protected Mode. I find that very unlikely, as it would be blatantly unfair to Vista.
I said it's more like that they simply used Firefox in the case where the machine was compromised. The rules stated that they installed "popular" 3rd party applications, and Firefox would certainly qualify as popular.
Also, your conclusions about UAC are completely wrong. I refer you to several blog posts I've written on the subject. UAC is a solution to a problem that only exists on Windows.
Well, I'm not sure how to reply to this. You're suggesting that I came to my conclusion because I assume that Microsoft's software is perfect. I did not. If you had read my entire post, you would have quickly realized this.
The fact that they specifically stated the exploit was in Flash, and did not mention any major compromise of protected mode or privilege escalations, suggests that there were none.
So what is more likely: the people running a high profile hacking contest didn't mention that the Vista machine was compromised not due to a single Flash buffer overflow, but instead a series of huge exploits in both Protected Mode and the Windows security subsystems. Or that the people running the high profile hacking contest neglected to mention that were using Firefox.
So next time you feel like talking down to the poor deluded Microsoft defender, try examining your own logic a bit first.
No. The low rights user has access to a limited number of registry entries, isolated storage (temp directory a few others under the user's profile), but has absolutely no access to virtualy anything else... especially the user's documents.
A broker service is used when reading or writing to user files (such as when they save a file to their desktop, or upload a document to a web site). This isolates the potentially dangerous code into a very small (~10k lines) application that is far easier to audit. This application runs as the normal user, and essentially accepts requests from the low rights IE process when actions need to be performed on user files.
That is not correct. Protected Mode's low rights user has virtually no access to the system.
Unless that file was specfically marked readable by the low rights user (which would be obvious cheating), or unless it was placed in a directory accessible by that user (temp directory, for instance), they could not have been using IE.
If the person on the Vista laptop was running IE 7 with the default configuration (protected mode / UAC on), this should not have happened.
Flash, like all other plugins, run within the security context of the low-rights user used by protected mode. Even if the flash plugin had an obvious buffer overflow or other exploit, it would only be able to access the data accessible by that low rights user, NOT the user running IE. That's the point of protected mode.
For a flash plugin to allow for a hacker to access personal files of the user it would not only have to have a buffer overflow (or some other exploit) in flash itself, but also take advantage of a privledge elevation exploit in Windows simultaneously.
I didn't see them specify in the article what browser than were using. Since they said it was an issue with flash, and not Windows, they couldn't have been using IE. My guess is that it was Firefox, since they said they loaded "popular" 3rd party apps.
Futhermore, the file in question must have been accessible to the user running Firefox (or whatever non-IE browser) since that would also require a privledge elevation in Windows.
So I'm not really sure how you can blame this on Vista or even Microsoft. If they had been using IE, it wouldn't have happened, regardless of the flaws in Flash. This says absolutely nothing about Vista security. The exact same thing would happen on every other OS. If you have an app with an exploit, and that app is running as User A, the hacker using that exploit has the same rights as User A.
I suppose one could argue that various defensive techniques like ASLR should have stopped this, but without knowing the details, that's impossible to say. A buffer overflow can just as easily be used to call APIs exposed by the exploited application as it can to call OS APIs, and since ASLR only applies to Windows APIs (indeed, many of these techniques only apply at the OS level), this wouldn't be a fair characterization either.
Indeed, I find it strange that they didn't mention mitigating factors. I realize they're trying to be responsible as far as reporting, but telling people that users running IE on Vista aren't affected isn't exactly giving anything away... aside from the fact that Vista did its job as best it could.
I know, I know... this is Slashdot, I shouldn't bother. But IE 7 on Vista (running in Protected Mode) is pretty damn secure.
While there have been exploits for IE 7, not a single one of them could successfully bypass Protected Mode. I'd say that's a pretty damn good track record for a browser that has been out for about a year and a half and has undoubtedly been targeted by many, many bad guys. (And good guys, for that matter.)
Slashdot Mirror
Ok, I just read most of the actual white paper (http://taossa.com/archive/bh08sotirovdowd.pdf) and this technique requires:
1.) A browser exploit that allows for a buffer overflow.
2.) A .NET control or Java applet loaded into the browser's memory whose PE header has been modified to include the malicious shell code.
Given these two things (only the 2nd of which is actually a given), you would still be constrained by Protected Mode in IE. In other words, the best you could do would be to crash the browser and maybe generate an error dialog of some sort.
If, however, the exploit was in a component that used a broker class to facility communications with a browser plugin, and that broker class was running as the current user, then you could at least access that user's files/data. If the broker class was running as system (which none do), you could take over the machine.
Flash is an example of a BAD, BAD plugin that has a broker class which could be used to facilitate an attack like this.
But let me reiterate that you first need an exploit, and that exploit must be one in an existing browser plugin (basically just Flash) that has a brokering mechanism that bypasses Protected Mode.
Without that, this doesn't do jack. Really, this is just a reliable way to defeat DEP/ASLR. Nothing more. It just makes the Flash exploit used in the hacking contest a few months back a bit more interesting. That exploit has since been patched, btw.
This is bad, but very, very overhyped.
Except that a large number of the features in Cairo made it into various Microsoft products over the years.
And that's kind of the point of a research product... to come up with ideas, see if they work, and then incorporate them into commercial products where it makes sense.
Thanks for laying that out. I do understand what Microsoft is trying to do with Midori.
I didn't talk about these aspects of the project because I wasn't trying to explain Midori as a whole, just that Slashdot's article summary was stupid.
How is this copying the "Unix server/client" model?
Do you even understand the most basic aspects of what they're attempting?
How as DCOM/COM+ a failure?
Your attitude is pretty silly. Obviously security of connected systems is important.
I don't think that these things ever were synonymous with being web-based.
The web is the World Wide Web. It's that thing you look at view a web browser. It uses HTTP as its primary protocol. It's connectionless. It's meant primarily as a mechanism for viewing content, although it has been co-opted as an application communications mechanism due to its simplicity, ubiquitousness, and easy of development.
None of these things has anything to do with the design of Midori.
Midori will *not* be "web based", whatever the hell that means.
Being "internet centric" and connected to "the cloud" is not the same has being web based.
Midori is being designed in such a way that components of the OS communicate with each other in a location independent manner. API calls to a local machine are no different than API calls to a remote machine. These calls will also be "message based" (there are lots of ways to interpret that) and be transactional in nature.
Above these kinds of low level things, there will be a much tighter and more integrated connection to the network. Your profile will roam with you no matter where you are using P2P style communications similar to how Live Mesh works, although supported by core OS components instead of via RSS synchronization.
So if your idea of a "web based" OS is like what I've described above, then yes... it's web based.
But if you're thinking about a subscription-based model where a user must boot their OS "from the web" like a dumb terminal, then you're way off.
Lastly, this thing is at least 7 to 10 years off. Windows 7 will ship sometime next year (or perhaps early in 2010), and Midori isn't even out of MS Research yet. If we saw something like this before Windows 8 / 2015, I'd be damn surprised.
After reading up about it, I think you're right.
See: http://en.wikipedia.org/wiki/Evidence_(law)#Circumstantial_evidence
Why do you think it took precedence over the facts?
The guy removed the seat of his car the day after his wife went missing and hoses the entire thing down.
Do you not think that this particular fact is relevant and that it may have had a pretty big impact on the jury?
If he behaved strangely and offers pretty implausible explanations of seemingly ambiguous facts, then you might have a point.
But he offered implausible explainations of things that point DIRECTLY at him as a murderer.
I don't know whether or not Hans is guilty.
I do think that convicting somebody based on circumstantial evidence is almost always a bad idea. In fact, it's such a bad idea, it usually doesn't happen... and when it does, the judge often steps in and overturns the conviction.
In this case, you have a guy who did some things that are pretty damn hard to explain away. The day after his wife goes missing he removes the passenger seat from his car and hoses the entire thing down? Seriously?
Should that be enough to convict him? I don't know. What I do know is that I find it very strange that so many of you are willing to ignore things like that and declare your outrage about his conviction.
Now that he has been found guilty, perhaps you should explain why you think he is innocent?
Anyway, here is the simple explanation that I've found helps people realize their error in thinking: The problem is a lot easier if you think about it in an "outcome" based fashion.
In other words, what are the three possible outcomes given that the person always switches their door?
[car] [goat] [goat]
Choose door 1. Host reveals door 3. Switch to door 2. NO CAR.
Choose door 2. Host reveals door 3. Switch to door 1. CAR.
Choose door 3. Host reveals door 2. Switch to door 1. CAR.
What are the three results? NO CAR, CAR, and CAR. In other words, always switching your answer results in a 2/3 chance of getting a car.
If we repeat this process but we never switch our door, you get:
Choose door 1. Host reveals door 3. No switch. CAR.
Choose door 2. Host reveals door 3. No switch. NO CAR.
Choose door 3. Host reveals door 2. No switch. NO CAR.
Now we only have a 1 in 3 chance of getting the car.
My blog posts are not wrong. There is a difference between graphical SUDO / the Mac OS X authorization prompt, and Vista's UAC.
The biggest difference is that Vista's UAC prompt is automated. Any attempt at doing something that requires admin access automatically results in a UAC prompt.
This is not what happens on Mac OS, and it is not what happens on Linux. In the case of Mac OS, their authorization prompt basically only appears when the user does things in the control panel, installs certain apps, or does file operations on locations they don't have access to.
In the case of Linux, most tasks that require admin access will just fail out right if you aren't running as su/root.
In both scenarios, the prompts only happen when they've been specifically coded for by the OS or application. This is fine, since the vast majority of applications written for these environments know this, and are designed with this in mind. Legacy software that doesn't play by the rules isn't an issue.
This is not the case with Windows. On Vista, a UAC prompt will happen any time any process attempts to do something that requires admin access but is not running as admin. If a crappy/legacy app calls to an API, or tries to write to a file, or whatever, and this action requires admin access, a UAC prompt automatically appears. In addition, when running as "admin" on Vista you're not really an admin (it only changes the UAC prompt so that not username/password is required).
Why would Microsoft do this if there weren't a huge body of legacy software that would simply break if it was not running as admin? It is a *fact* that UAC is a compatibility mechanism... Microsoft has repeated stated this. Not only that, but a huge part of UAC is heuristic based... so it can detect the potential for requiring admin access ahead of time. This is particularly useful with installers, control panel apps (.cpl), etc.
Sure the APIs have been there to play nice with NT-style permissions / user isolation... but Microsoft was horrible at enforcing that, even with XP. Lazy ISVs continued to do it the old way because it worked. The fact it was possible to do it the right way, or that you could "Run As Admin" has absolutely no bearing on this discussion.
These are not assumptions. These are facts. If the team that performed the hack found multiple exploits, they would have stated as much. For you to say they would not have is ridiculous. In fact, it was part of the rules that they explain exactly how the hack was performed. Windows is still carrying the baggage of a single-user system and as long as that is the case it will be easier to exploit. Huh? What does this have to do with the baggage of Windows' history? Seems to me that you are the one making assumptions. UAC does raise the barrier, but addresses a problem that only exists on Windows, since that OS still does not properly compartmentalize users the way other OSs do. You do realize that this has nothing to do with UAC, right? The file in question was accessible by the user running the browser. It didn't require admin privs. Protected Mode and UAC are two entirely different things. I'll assume, for the moment, that you're no longer talking about Protected Mode, IE, and this exploit and instead have switched topics to my blog posts regarding Windows' history and why UAC is necessary.
You obviously didn't understand my blog posts because UAC being necessary has nothing to do with any deficiencies in Windows with regards to the ability to "compartmentalize users". The fundamental security model behind Windows is every bit as capable (and, indeed, more advanced in may ways) as Linux. The problem is that there were two distinct branches of Windows: NT and 9x. When these two branches were merged, it was absolutely necessary to ensure that the 9x software ran on the NT-based versions of Windows.
As I mentioned in my blog post in great detail, it was this support for legacy software that resulted in Windows defaulting to admin on XP, and eventually to Vista needing UAC. UAC is, for the most part, a compatibility mechanism, not a security boundary.
In fact, the only big difference between UAC and the way the Mac handles this is that the Mac doesn't have any mechanism to automatically detect admin operations... so if an application tries to perform an action that requires admin privs, and it doesn't have them, it will just fail. On Vista, it will prompt the user. The same goes for Linux. Applications trying to perform admin operations that don't have perms will just fail and error out. Can you see why that would be an issue on an OS with literally millions of software titles that assume admin access? My own logic is sound. But I suggest that next time you feel like discussing such things, you rely on facts and leave assumptions at the door. No, your logic is not sound. It is clear to me, and probably most other people reading these comments, that it is you making assumptions.
Wow. Now I hate Flash even more than I did before.
UAC only protects you against against that require admin rights. An exploit can still delete the files in your Documents folder with no prompt.
DEP prevents certain types of buffer overflows, but not all of them, and it requires hardware support. (Although most CPUs have support, these days.)
The Mozilla team is working on supporting Protected Mode in the near future. They've actually praised Microsoft's for their help with this.
Honestly, I'll probably go back to using Firefox once it supports Protected Mode.
I was not aware that Flash did this. This would certain explain how it was possible without resorting to using Firefox, or some other browser, as the host for Flash.
Can you post some documentation that details this? It must be new for the Vista/IE version of Flash, since I can't think of any reason why they would have done this pre-Vista.
I never suggested that they turned off UAC or Protected Mode. I find that very unlikely, as it would be blatantly unfair to Vista.
I said it's more like that they simply used Firefox in the case where the machine was compromised. The rules stated that they installed "popular" 3rd party applications, and Firefox would certainly qualify as popular.
Also, your conclusions about UAC are completely wrong. I refer you to several blog posts I've written on the subject. UAC is a solution to a problem that only exists on Windows.
See the following: background info, and most of this post deals with UAC.
Well, I'm not sure how to reply to this. You're suggesting that I came to my conclusion because I assume that Microsoft's software is perfect. I did not. If you had read my entire post, you would have quickly realized this.
The fact that they specifically stated the exploit was in Flash, and did not mention any major compromise of protected mode or privilege escalations, suggests that there were none.
So what is more likely: the people running a high profile hacking contest didn't mention that the Vista machine was compromised not due to a single Flash buffer overflow, but instead a series of huge exploits in both Protected Mode and the Windows security subsystems. Or that the people running the high profile hacking contest neglected to mention that were using Firefox.
So next time you feel like talking down to the poor deluded Microsoft defender, try examining your own logic a bit first.
No. The low rights user has access to a limited number of registry entries, isolated storage (temp directory a few others under the user's profile), but has absolutely no access to virtualy anything else... especially the user's documents.
A broker service is used when reading or writing to user files (such as when they save a file to their desktop, or upload a document to a web site). This isolates the potentially dangerous code into a very small (~10k lines) application that is far easier to audit. This application runs as the normal user, and essentially accepts requests from the low rights IE process when actions need to be performed on user files.
That is not correct. Protected Mode's low rights user has virtually no access to the system.
Unless that file was specfically marked readable by the low rights user (which would be obvious cheating), or unless it was placed in a directory accessible by that user (temp directory, for instance), they could not have been using IE.
If the person on the Vista laptop was running IE 7 with the default configuration (protected mode / UAC on), this should not have happened.
Flash, like all other plugins, run within the security context of the low-rights user used by protected mode. Even if the flash plugin had an obvious buffer overflow or other exploit, it would only be able to access the data accessible by that low rights user, NOT the user running IE. That's the point of protected mode.
For a flash plugin to allow for a hacker to access personal files of the user it would not only have to have a buffer overflow (or some other exploit) in flash itself, but also take advantage of a privledge elevation exploit in Windows simultaneously.
I didn't see them specify in the article what browser than were using. Since they said it was an issue with flash, and not Windows, they couldn't have been using IE. My guess is that it was Firefox, since they said they loaded "popular" 3rd party apps.
Futhermore, the file in question must have been accessible to the user running Firefox (or whatever non-IE browser) since that would also require a privledge elevation in Windows.
So I'm not really sure how you can blame this on Vista or even Microsoft. If they had been using IE, it wouldn't have happened, regardless of the flaws in Flash. This says absolutely nothing about Vista security. The exact same thing would happen on every other OS. If you have an app with an exploit, and that app is running as User A, the hacker using that exploit has the same rights as User A.
I suppose one could argue that various defensive techniques like ASLR should have stopped this, but without knowing the details, that's impossible to say. A buffer overflow can just as easily be used to call APIs exposed by the exploited application as it can to call OS APIs, and since ASLR only applies to Windows APIs (indeed, many of these techniques only apply at the OS level), this wouldn't be a fair characterization either.
Indeed, I find it strange that they didn't mention mitigating factors. I realize they're trying to be responsible as far as reporting, but telling people that users running IE on Vista aren't affected isn't exactly giving anything away... aside from the fact that Vista did its job as best it could.
I know, I know... this is Slashdot, I shouldn't bother. But IE 7 on Vista (running in Protected Mode) is pretty damn secure.
While there have been exploits for IE 7, not a single one of them could successfully bypass Protected Mode. I'd say that's a pretty damn good track record for a browser that has been out for about a year and a half and has undoubtedly been targeted by many, many bad guys. (And good guys, for that matter.)
I'm sorry to disturb your twisted view of reality with a little dose of skepticism.
I'll never do it again.
Dozens? Seriously? So that represents, what, about .0005% of users installing SP1?
Why is it news that a few dozen people have issues with a service pack installation? Oh, that's right... this is Slashdot.
Slashdot should just get it over with and change their slogan to "News for people who hate Microsoft. Stuff that we made up."