So, the committee as a population says 'no', then the executive members of the committee (in your terms, and President Bush's, the 'decision makers') decide to submit a 'yes' vote and give a very vague justification for why they overruled the committee. What I'm saying, or at least trying to talk through, is that it seems like if it happened this way, then the rules of these orgs allow the executive members to overrule the vote.
If thats the case, then, according to the rules, it was done properly.
It's tough to talk coherently about these meetings though because they dont seem to publish their rules of organization or meetins or anything that I can find online. So its hard to make an informed decision about whether the rules were violated or not.
Now thats not saying that even if they were not violated that it was a good decision. My biggest gripe of the OOXML proposal has been the fast-track, which is clearly not the right venue for this iso proposal.
But that being said, I think this whole process says much more about the ISO orgs than it does about Microsoft or business in general. Because it seems as if the ISO national orgs are setup to allow this to happen. Which means MS played to the letter, if not the spirit, of the rules.
To be clear, I'm not arguing in favor of or against the OOXML proposal. My thoughts here are more about the ISO process itself, and that it seems to be quite easy to game.
What I'd love to see are some thoughts from folks who have been part of these processes for years, and see if this is normal or abnormal behavior for these orgs. In other words, does this happen every time a proposal comes up that is central to some company's financial success? Its possible that it does, just at a smaller scale. Leave it to Microsoft to go big on something like this.
Okay, I'm not familiar with the internal rules of national ISO committees, but it sounds like in all those cases that the decision makers made a decision. And in some cases it was in disagreement with their technical advising committees.
So maybe it wasnt a good decision, but I am not seeing bribing or corruption here.
In other words, if the people who cast the final vote werent the actual decision makers, then why would the ISO accept their vote? If they are the decision makers, then it was properly done, just unpopular.
Of course, its possible that the meeting rules require a binding democratic vote of all present, but I cant find any online documentation that says yay or nay on that.
What exactly are the downsides to archiving mail in a pst, keeping a local copy for offline access, and having a copy that gets backed up to the network share on a regular basis? Downsides:
1. No backups of your PST. If its on the server, its getting backed up automatically (one hopes). At best, in your suggestion, you have to use a supplementary backup process in addition to the primary one.
2. Your mail only exists on one machine. So you cant OWA from somewhere else, and you cant easily move between your regular machine and another machine.
3. Not necessary for offline access. Outlook caches the entire mailboxes locally and transitions between online and offline seamlessly by default (since Outlook 2003).
4. PSTs are easy to corrupt. This pretty much never happens on a properly maintained Exchange server.
About the only real upside to local PSTs is that it makes an easy out if you get sued. Since PST storage is 'unofficial' and not known or monitored by the central IT, then if your company gets subpoena'd, the sysadmins just give up what's on exchange. At least theoretically, I'm not sure how well that works in practice. Attorneys are canny.
Not quite. The guy who brought down the Vista box made a point in saying that the exploit is useful against OSX and Linux as well, they just need a bit more work to tune it.
The reason you didnt see the others taken down is that this was a privately-found vuln by this company, and you can only use a vuln once. By contest rules you cant use the same vulnerability on all three systems. So they chose to target Windows.
The baggage of supporting legacy apps that require(d) administrator access. Because Windows had been designed for so long to be run by a single user-administrator, there are plenty of apps that simply won't run without admin-level privileges.
I'm not sure where you get this from. Windows was never designed this way. Many userspace applications were, but the OS itself never was. It's been multi-user from the start.
Not exactly. When an OS is designed from the ground up as a multiuser system (such as *nix), it is very easy to restrict access to system resources. If I want to install a piece of software on Linux, for example, I cannot make the installation system-wide (by writing to/usr/bin, for example) without admin privileges. I cannot install libraries to/lib,/usr/lib, etc. I cannot write settings to/etc. Even when installed and executed, that program will only have a restricted set of rights based on the user/group that executes it. I can, however, compile and run executables as a user without needing admin access and without write access to system files and/or directories. I can put whatever libraries, modules, settings etc are required in my home directory without needing access to restricted areas.
Yes, I do run the risk of hosing my/home/user directory and everything inside of it, but I cannot touch any other user's files, and cannot touch system files.
The way you describe Unix as working is _precisely_ how windows works. In every single way that you describe here, windows works exactly the same.
Windows, on the other hand, has a hybrid model where a multi user model is tacked onto a single user-admin model, or rather support for a single user-admin model is bolted onto a basic multiuser model.
Like many on/., I dont think you understand how the technical internals of windows works. Yet you are free about complaining about how you think it works is bad.
Basic, because a true multi-user system would never have a single repository for all settings, like the Windows registry.
I think you're conflating unrelated things. And adding that onto a fundamental misunderstanding of how windows works.
Windows does NOT have a single repository for all settings.
It has one primary configuration file, which is the HKLM registry hive. In addition to that, there are a large number of other secondary configuration files in windows\system32 and subfolders.
Each user also has its own registry hive file. In addition to that, there are a large number of other secondary and application specific configuration files stored in their user profile (ie, what you call a home folder).
The OP said that because IE7 isn't supposed to allow a system level exploit via something like Flash, then therefore it isn't possible. My sysadmin said that because she configured Exchange to block autoforwarding to public webmail then it isn't possible.
Again, you're conflating unrelated things. Just because your Exchange admin was ignorant as to the holistic system which included Exchange, does not mean that Windows is broken, or even the more specific case of that IE7's protected mode is broken. The two are completely unrelated.
Your Exchange admin's issue was one of profound human ignorance of a matter, compounded by the ignorant person making sweeping statements about things with which they were ignorant. Much like you did in your post.
The IE7 issue was one of some of us not knowing the whole story. As those of us who read up on the IE7 Protected Mode system know, there is the concept of a broker that can be built to allow plugins that need it the ability to communicate with the outside world.
Adobe apparently installs one of these (this was the new piece of information) in Vista, and then allows fairly arbitrary commands to be passed through the broker.
The gentleman who took down the Vista box claims that the vuln is usable against OSX and Linux as well, just requires a few more hours of work from them to setup.
Also, I just found out while reading some other posts that the way this gets around IE7 Protected Mode is that Flash sets up a broker service that lets flash running in protected mode ignore protected mode. You've got to love it.
I believe you can effectively do this on linux in one of a couple ways:
setuid/seteuid
and I think the AppArmor and SELinux gives you some abilities in this area.
Not my area of expertise however, so cant say definitively.
Apparently though, after reading this post I think Flash sets up something that effectively disables Protected Mode in IE7 for it. Which is quite irritating.
Well how about instead of making silly statements like this, you go read the documentation on IE7 protected mode. It quite thoroughly answers your question.
I'll even be nice and give you some of the information.
There are special cache locations in the registry and user profile called 'Low' that are the only places readable/writeable by IE7 in protected mode.
I did mis-speak in one sense in my post.... protected mode primarily restricts the browser process from WRITING to almost everywhere. I dont believe it restricts reading any more than the regular user account that its run under has rights to.
1. The contest did not require someone to 'own' the box to win. They just had to read the contents of some specific file somewhere in the OS. Unfortunately, they didnt publish where that file was, or what the file-system ACLs on it were.
2. The guy who took down the Vista box claimed in the article that it would only take them a few more hours of work to make the Flash vuln effective on OSX and Linux as well.
In Vista, they must have found a way to get out of the flash process space, into the OS without the Cancel/Allow Continue/Cancel prompts to control the box. Then they have the systems. Remember, they have to do more than just crash or execute a few bytes, they must pwn the system. Not necessarily.
The way to win the contest was not to modify the system, but to read the contents of 'some file' 'somewhere' in the OS (but they dont publish where that is, or what file system ACLs it has set).
Depending on where that is (ie, browser cache) then this may be a trivial contest, but I doubt if that was the case.
They also didnt publish whether Flash was owned through firefox or IE7, and if IE7 whether it was on a site in Trusted Zone or Internet zone.
Flash on Firefox is probably the easiest attack vector, as IE7 in 'Protected Mode' is pretty well sandboxed.
It's implied, but I cant find any specific listing on the cansecwest site. They also dont say where the file to be read was, or what the file-system ACLs were on it.
Its worthy of note that the attacker that took down the Vista box claims that its only a few hours of work from being successful against OSX and Linux as well. Not substantiated, but claimed.
The level of ignorance about the technical underpinnings of Windows on/. is appalling.
Browsers and their plugins have access to everything. Incorrect. Browsers and their plugins have access to whatever security account they are being run as. Typically thats a non-priv'd user using the desktop. This means read access to most of the OS and write access to their profile area and some common temp areas. Pretty much like any other mainstream OS in fact.
Do something as simple as post a picture in myspace and you will see that it has access to let you browse the entire system to find your picture. Any number of sites will let you browse for files through said browser. Thats because YOU (ie, the account of the person who launched the browser) has access to read most of the file system. Note that this isnt some magical ActiveX control that is installed by the browser. A file-browser with upload capability is built into every browser.
If a simple scriptlet can do that, its not like you say. This isnt the behavior of a scriptlet, its functionality built into the browser.
Anyone who has ever used Internet explorer to install a printer through IIS will tell you it happens. I connect to the web page at my work, and IE lets me not only connect, but it also downloads and installs print drivers. Something like that has access to system areas and even registry. Again, only if you have permission to install that printer in the first place. This is no different than the 'click n print' functionality you use all the time in a domain. Type \\servername\ into explorer, then double click one of the printers there.
And this only works if the server in question is in your Trusted Sites or Intranet Sites in IE.
Non-admin users installing printer drivers is something that is controllable via AD and Group Policy. If you set it, it loosens up acls and privs in a very specific and limited part of the system that lets non-admin users install printers.
This isnt rocket science or magic.
One could exploit that to create a faux driver and do malicious activity with it. Only if several things line up together:
1. The server who hosts this printer driver is in your IE's Trusted Locations or Intranet Locations.
2. The configuration to let non-admin users install printer drivers is set on your machine.
3. There is a hole big enough within the security loosening from #2 to do anything interesting with to own the OS.
Dude, where do you get your information? Your whole post is based on completely inaccurate information.
IE has NEVER run as SYSTEM on any NT based version of Windows. Suggesting otherwise is just flat making crap up.
IE or Firefox on WinXP run as the user account of the user who launches it.
IE7 on Vista is much better protected, as it runs as a user account with al the security tokens stripped, so basically has zero perms to read or write to the file system, other than a very small number of cache locations.
I know its the trendy thing to do here on/. to buy into the groupthink and swallow whatever crap Twitter tells you, but thats just nonsense.
On a typical Linux distro, the web browser runs as the same user/privs as the person using the desktop, so anything that can cause the browser or browser-plugin to reach outside of the app's sandbox can quite easily read/write to anything on the box that the desktop user can read/write to/from. Same for WinXP.
But on Vista using IE7, this is very much not the case. Even if you completely pwn the browser, its running as a user process that has almost zero ability to write or read anywhere on the file system.
Which makes me wonder if this attack was via Flash on Firefox, which would be much more vulnerable to this type of disclosure attack than Flash on IE (as long as the site wasnt in Trusted Sites on the IE).
Now mind you, some of the mandatory acccess control packages on linux systems can strongly mitigate this, much like IE7 on Vista. I cant say whether these would apply to Firefox, say, on a typical Linux distro though.
the contest was to in a 30 minute attack slot, read the contents of a specific file, in a specific folder. It's so frustrating that more information isnt provided.
Reading the contents of a file in a folder can range from very difficult to very easy, depending on the details.
If its a file in the browser cache folder that the browser and anything running through the browser has access to, then its a fairly meaningless contest.
If its a file in the users profile somewhere that the desktop user has access to, but most typical apps (browser, etc) wont have access to normally, then thats slightly more difficult.
If its a file in a folder where the file system acl's deny read to the user on the desktop, then thats a much, much harder attack scenario than the others.
The interesting thing here is that if the Flash vuln was running on IE, it should have been ineffective against the OS, unless somehow the Flash executable somehow creates an escalation vulnerability in the OS (which obviously is silly).
I wonder if Flash was attacked via Firefox, or in some other fashion. Through IE, running as a non-admin and with the IE7 on Vista sandboxing, any vuln in flash should have been pretty useless in owning the OS.
I wish there were more details posted.
Also interesting that the folks who took down the Vista box said its a couple hours of work from this being effective against OSX and Linux as well.
That said, when clients of mine buy new Dells with XP today, they ship with roughly 90+ security patches to XP non-applied, and IE6 still loaded. Yeah, that is a royal pain, agreed.
Will be interesting to see what happens when XP SP3 releases, what the patching situation will look like then.
like happens to most unpatched Windows machines that get nailed by drive-bys For what its worth, I am not aware (and just did a quick review of secunia) of a single drive-by attack vector that affects vista in a default configuration (UAC, and IE7 running in protected mode).
Even the animated cursor attack right after vista came out is blocked by both ie7 protected mode and running as non-admin.
And despite that, neither the vista box nor the ubuntu box were hacked at all on day 2.
Day 2 allowed user interaction (like browsing to a website) but only allowed targeting software that ships with the product.
That being said... there was one unusual rule. Only non-published exploits could be used. So, for example, if there was a published but still unpatched vuln in vista or ubuntu, those couldnt be used.
So part of this was timing or withheld disclosure. For example, it seems to me that a security company could find a hole and then sit on it and never disclose and save it until cansecwest.
had safari been on any other OS with that flaw the other OSes would be fscked as well no questions asked. Maybe. Both windows and linux have significant tools in their code to mitigate buffer overflows. Stack canaries, NX bit set, etc etc.
Particularly stack based buffer overflows are well protected nowadays.
Not sure how many of these OSX has, though could just be my ignorance on the matter.
Slashdot Mirror
If thats the case, then, according to the rules, it was done properly.
It's tough to talk coherently about these meetings though because they dont seem to publish their rules of organization or meetins or anything that I can find online. So its hard to make an informed decision about whether the rules were violated or not.
Now thats not saying that even if they were not violated that it was a good decision. My biggest gripe of the OOXML proposal has been the fast-track, which is clearly not the right venue for this iso proposal.
But that being said, I think this whole process says much more about the ISO orgs than it does about Microsoft or business in general. Because it seems as if the ISO national orgs are setup to allow this to happen. Which means MS played to the letter, if not the spirit, of the rules.
To be clear, I'm not arguing in favor of or against the OOXML proposal. My thoughts here are more about the ISO process itself, and that it seems to be quite easy to game.
What I'd love to see are some thoughts from folks who have been part of these processes for years, and see if this is normal or abnormal behavior for these orgs. In other words, does this happen every time a proposal comes up that is central to some company's financial success? Its possible that it does, just at a smaller scale. Leave it to Microsoft to go big on something like this.
Okay, I'm not familiar with the internal rules of national ISO committees, but it sounds like in all those cases that the decision makers made a decision. And in some cases it was in disagreement with their technical advising committees.
So maybe it wasnt a good decision, but I am not seeing bribing or corruption here.
In other words, if the people who cast the final vote werent the actual decision makers, then why would the ISO accept their vote? If they are the decision makers, then it was properly done, just unpopular.
Of course, its possible that the meeting rules require a binding democratic vote of all present, but I cant find any online documentation that says yay or nay on that.
Just out of curiosity, why dont you just log into your desktop as non-admin, but then run vs2005 with runas?
1. No backups of your PST. If its on the server, its getting backed up automatically (one hopes). At best, in your suggestion, you have to use a supplementary backup process in addition to the primary one.
2. Your mail only exists on one machine. So you cant OWA from somewhere else, and you cant easily move between your regular machine and another machine.
3. Not necessary for offline access. Outlook caches the entire mailboxes locally and transitions between online and offline seamlessly by default (since Outlook 2003).
4. PSTs are easy to corrupt. This pretty much never happens on a properly maintained Exchange server.
About the only real upside to local PSTs is that it makes an easy out if you get sued. Since PST storage is 'unofficial' and not known or monitored by the central IT, then if your company gets subpoena'd, the sysadmins just give up what's on exchange. At least theoretically, I'm not sure how well that works in practice. Attorneys are canny.
Not quite. The guy who brought down the Vista box made a point in saying that the exploit is useful against OSX and Linux as well, they just need a bit more work to tune it.
The reason you didnt see the others taken down is that this was a privately-found vuln by this company, and you can only use a vuln once. By contest rules you cant use the same vulnerability on all three systems. So they chose to target Windows.
The baggage of supporting legacy apps that require(d) administrator access. Because Windows had been designed for so long to be run by a single user-administrator, there are plenty of apps that simply won't run without admin-level privileges.
I'm not sure where you get this from. Windows was never designed this way. Many userspace applications were, but the OS itself never was. It's been multi-user from the start.
Not exactly. When an OS is designed from the ground up as a multiuser system (such as *nix), it is very easy to restrict access to system resources. If I want to install a piece of software on Linux, for example, I cannot make the installation system-wide (by writing to /usr/bin, for example) without admin privileges. I cannot install libraries to /lib, /usr/lib, etc. I cannot write settings to /etc. Even when installed and executed, that program will only have a restricted set of rights based on the user/group that executes it. I can, however, compile and run executables as a user without needing admin access and without write access to system files and/or directories. I can put whatever libraries, modules, settings etc are required in my home directory without needing access to restricted areas.
/home/user directory and everything inside of it, but I cannot touch any other user's files, and cannot touch system files.
Yes, I do run the risk of hosing my
The way you describe Unix as working is _precisely_ how windows works. In every single way that you describe here, windows works exactly the same.
Windows, on the other hand, has a hybrid model where a multi user model is tacked onto a single user-admin model, or rather support for a single user-admin model is bolted onto a basic multiuser model.
Like many on /., I dont think you understand how the technical internals of windows works. Yet you are free about complaining about how you think it works is bad.
Basic, because a true multi-user system would never have a single repository for all settings, like the Windows registry.
I think you're conflating unrelated things. And adding that onto a fundamental misunderstanding of how windows works.
Windows does NOT have a single repository for all settings.
It has one primary configuration file, which is the HKLM registry hive. In addition to that, there are a large number of other secondary configuration files in windows\system32 and subfolders.
Each user also has its own registry hive file. In addition to that, there are a large number of other secondary and application specific configuration files stored in their user profile (ie, what you call a home folder).
The OP said that because IE7 isn't supposed to allow a system level exploit via something like Flash, then therefore it isn't possible. My sysadmin said that because she configured Exchange to block autoforwarding to public webmail then it isn't possible.
Again, you're conflating unrelated things. Just because your Exchange admin was ignorant as to the holistic system which included Exchange, does not mean that Windows is broken, or even the more specific case of that IE7's protected mode is broken. The two are completely unrelated.
Your Exchange admin's issue was one of profound human ignorance of a matter, compounded by the ignorant person making sweeping statements about things with which they were ignorant. Much like you did in your post.
The IE7 issue was one of some of us not knowing the whole story. As those of us who read up on the IE7 Protected Mode system know, there is the concept of a broker that can be built to allow plugins that need it the ability to communicate with the outside world.
Adobe apparently installs one of these (this was the new piece of information) in Vista, and then allows fairly arbitrary commands to be passed through the broker.
The gentleman who took down the Vista box claims that the vuln is usable against OSX and Linux as well, just requires a few more hours of work from them to setup.
Also, I just found out while reading some other posts that the way this gets around IE7 Protected Mode is that Flash sets up a broker service that lets flash running in protected mode ignore protected mode. You've got to love it.
Thank you for posting this .... I didnt know that Adobe added a broker to IE7. This is useful information.
Maybe, maybe not.
The guy that took down Vista claims that the same exploit can be used on Linux and OSX, just requires a few more hours work.
Not proven yet, but possible.
I believe you can effectively do this on linux in one of a couple ways:
setuid/seteuid
and I think the AppArmor and SELinux gives you some abilities in this area.
Not my area of expertise however, so cant say definitively.
Apparently though, after reading this post I think Flash sets up something that effectively disables Protected Mode in IE7 for it. Which is quite irritating.
You can parent up a few times to see the context.
Well how about instead of making silly statements like this, you go read the documentation on IE7 protected mode. It quite thoroughly answers your question.
.... protected mode primarily restricts the browser process from WRITING to almost everywhere. I dont believe it restricts reading any more than the regular user account that its run under has rights to.
I'll even be nice and give you some of the information.
There are special cache locations in the registry and user profile called 'Low' that are the only places readable/writeable by IE7 in protected mode.
I did mis-speak in one sense in my post
A couple things to note of interest:
1. The contest did not require someone to 'own' the box to win. They just had to read the contents of some specific file somewhere in the OS. Unfortunately, they didnt publish where that file was, or what the file-system ACLs on it were.
2. The guy who took down the Vista box claimed in the article that it would only take them a few more hours of work to make the Flash vuln effective on OSX and Linux as well.
The way to win the contest was not to modify the system, but to read the contents of 'some file' 'somewhere' in the OS (but they dont publish where that is, or what file system ACLs it has set).
Depending on where that is (ie, browser cache) then this may be a trivial contest, but I doubt if that was the case.
They also didnt publish whether Flash was owned through firefox or IE7, and if IE7 whether it was on a site in Trusted Zone or Internet zone.
Flash on Firefox is probably the easiest attack vector, as IE7 in 'Protected Mode' is pretty well sandboxed.
It's implied, but I cant find any specific listing on the cansecwest site. They also dont say where the file to be read was, or what the file-system ACLs were on it.
Its worthy of note that the attacker that took down the Vista box claims that its only a few hours of work from being successful against OSX and Linux as well. Not substantiated, but claimed.
The contest didnt require you to do any damage to the system.
The contest required that the attack be able to read a file 'somewhere' on the OS.
Unfortunately, they dont tell us where that file was, or what the ACLs on it were, so its hard to make any sort of sane judgement about it.
And this only works if the server in question is in your Trusted Sites or Intranet Sites in IE.
Non-admin users installing printer drivers is something that is controllable via AD and Group Policy. If you set it, it loosens up acls and privs in a very specific and limited part of the system that lets non-admin users install printers.
This isnt rocket science or magic. One could exploit that to create a faux driver and do malicious activity with it. Only if several things line up together:
1. The server who hosts this printer driver is in your IE's Trusted Locations or Intranet Locations.
2. The configuration to let non-admin users install printer drivers is set on your machine.
3. There is a hole big enough within the security loosening from #2 to do anything interesting with to own the OS.
Dude, where do you get your information? Your whole post is based on completely inaccurate information.
/. to buy into the groupthink and swallow whatever crap Twitter tells you, but thats just nonsense.
IE has NEVER run as SYSTEM on any NT based version of Windows. Suggesting otherwise is just flat making crap up.
IE or Firefox on WinXP run as the user account of the user who launches it.
IE7 on Vista is much better protected, as it runs as a user account with al the security tokens stripped, so basically has zero perms to read or write to the file system, other than a very small number of cache locations.
I know its the trendy thing to do here on
Actually, I'd say you've got it backwards.
On a typical Linux distro, the web browser runs as the same user/privs as the person using the desktop, so anything that can cause the browser or browser-plugin to reach outside of the app's sandbox can quite easily read/write to anything on the box that the desktop user can read/write to/from. Same for WinXP.
But on Vista using IE7, this is very much not the case. Even if you completely pwn the browser, its running as a user process that has almost zero ability to write or read anywhere on the file system.
Which makes me wonder if this attack was via Flash on Firefox, which would be much more vulnerable to this type of disclosure attack than Flash on IE (as long as the site wasnt in Trusted Sites on the IE).
Now mind you, some of the mandatory acccess control packages on linux systems can strongly mitigate this, much like IE7 on Vista. I cant say whether these would apply to Firefox, say, on a typical Linux distro though.
Reading the contents of a file in a folder can range from very difficult to very easy, depending on the details.
If its a file in the browser cache folder that the browser and anything running through the browser has access to, then its a fairly meaningless contest.
If its a file in the users profile somewhere that the desktop user has access to, but most typical apps (browser, etc) wont have access to normally, then thats slightly more difficult.
If its a file in a folder where the file system acl's deny read to the user on the desktop, then thats a much, much harder attack scenario than the others.
The interesting thing here is that if the Flash vuln was running on IE, it should have been ineffective against the OS, unless somehow the Flash executable somehow creates an escalation vulnerability in the OS (which obviously is silly).
I wonder if Flash was attacked via Firefox, or in some other fashion. Through IE, running as a non-admin and with the IE7 on Vista sandboxing, any vuln in flash should have been pretty useless in owning the OS.
I wish there were more details posted.
Also interesting that the folks who took down the Vista box said its a couple hours of work from this being effective against OSX and Linux as well.
Will be interesting to see what happens when XP SP3 releases, what the patching situation will look like then.
Wonder if it'll include IE7 by default, etc.
Even the animated cursor attack right after vista came out is blocked by both ie7 protected mode and running as non-admin.
Well, there's some truth to that.
... there was one unusual rule. Only non-published exploits could be used. So, for example, if there was a published but still unpatched vuln in vista or ubuntu, those couldnt be used.
However, there's also a $10,000 prize for today.
And despite that, neither the vista box nor the ubuntu box were hacked at all on day 2.
Day 2 allowed user interaction (like browsing to a website) but only allowed targeting software that ships with the product.
That being said
So part of this was timing or withheld disclosure. For example, it seems to me that a security company could find a hole and then sit on it and never disclose and save it until cansecwest.
Particularly stack based buffer overflows are well protected nowadays.
Not sure how many of these OSX has, though could just be my ignorance on the matter.
Last year was QT, this year was Safari.