ZERT, short for zero-day emergency response team, have released a patch for the microsoft VML vulnerability that has been recently uncovered and exploited...
there have been 3rd party patches in the past (the WMF one being a prime example) but the significance here is that an organization has formed (with an impressive set of members) specifically for the purpose of releasing 3rd party patches to vulnerabilities that are exploited before a patch is available from the vulnerable software's vendor...
i've mentioned 3rd party patches before and why they're needed (because certain vendors don't do enough to shut the window of exposure quickly enough)... i thought they were a good idea and i think they're an even better idea now... rumor has it that microsoft may release a patch for the VML vulnerability out of cycle (before the 2nd tuesday of next month) but this rumor only seems to have surfaced after ZERT released their 3rd party patch... furthermore, another rumor has it that microsoft was/is considering releasing an early patch for their onecare customers (which just goes to show what i said before about their being no moral high ground for microsoft in the security industry is proving moot because they clearly have no interest in the moral high ground)... i have no idea if the 2 rumors are related, but regardless of that it seems to me that 3rd party patches may serve to help keep microsoft honest in a way that full disclosure was supposed to do...
i can't mention ZERT's VML patch without drawing attention to what randy abrams has written about it, though... in spite of being a member of ZERT, he wisely posts words of caution over the use of their 3rd party patch that basically boil down to this: most people don't need or use VML in the first place and so the existing workaround of disabling it is a better option than the 3rd party patch under those circumstances - you should only need the 3rd party patch if you really need the vector graphics (not just regular graphics, mind you) rendering engine to operate, and then you should only need the 3rd party patch until the vendor releases their own patch... that's good advice and i think it can probably be applied to 3rd party patches in general, not just this one...
Showing posts with label 3rd party patch. Show all posts
Showing posts with label 3rd party patch. Show all posts
Saturday, September 23, 2006
Tuesday, April 04, 2006
why microsoft hates 3rd party patches
it's not exactly news anymore, but it's happened again - a bug has cropped up in microsoft's software that is so serious that outside parties have been forced to create patches for it due to microsoft's glacial pace...
microsoft doesn't like this, it doesn't like this one bit... it makes them look like chumps... here they are with full access to the source code, tens of thousands of developers, and billions of dollars to throw around and some guy at some security firm somewhere makes a patch faster than they can? they do not want these kinds of comparisons to happen, they do not want people to see what kind of performance the microsoft security machine is really giving them...
one of the things they say is that only microsoft patches are guaranteed to work with everything... they have all these tests they need to perform to make sure they don't break anything and comparing their process to what 3rd party patchers do just isn't fair... problem is, not only are microsoft's patches NOT guaranteed (there have been multiple instances where their patches inadvertently broke things) but it also underlines the fact that compatibility rather than security is their first priority... and this comes from a program manager at microsoft's security response center....
microsoft's security efforts are a failure, a farce, and the public has lost confidence in them... and not just a little bit of confidence either; the WMF incident back in december and now the new IE vulnerability just a few months later, both with wide adoption of 3rd party patches, indicates that this is a watershed event... confidence in microsoft's security efforts has crossed a threshold...
the worst thing, for microsoft at least, is that they're losing control over a captive market... 3rd party patches open the door for competition for their paid support program(s), as well as eat away at the leverage they have for getting people to upgrade by ending support for older versions of their products... ending support has a lot less meaning when other people are willing to pick up the slack...
microsoft talks a good game about security, i saw one of them talk about it at RSA2002, they go to great lengths, but they seriously underestimate the significance of risk when they leave the window of exposure open as long as they do while trying to make the perfect patch... when there's a serious exploit in the wild there should be no question of whether or not to release a patch out of cycle, it should be released as soon as it's made and refined and updated after the fact... so long as a seasoned expert at writing secure code is making the patch (rather than some green code monkey they're trying to train), any problems that might arise from a rushed patch are almost certainly going to be less severe than than the one it's supposed to fix... further, new vulnerabilities from a rushed patch would require additional time and effort from the attacker community to exploit so as long as the development of the patch continues after the initial release so that updates to the patch can be pushed out if needed...
microsoft doesn't like this, it doesn't like this one bit... it makes them look like chumps... here they are with full access to the source code, tens of thousands of developers, and billions of dollars to throw around and some guy at some security firm somewhere makes a patch faster than they can? they do not want these kinds of comparisons to happen, they do not want people to see what kind of performance the microsoft security machine is really giving them...
one of the things they say is that only microsoft patches are guaranteed to work with everything... they have all these tests they need to perform to make sure they don't break anything and comparing their process to what 3rd party patchers do just isn't fair... problem is, not only are microsoft's patches NOT guaranteed (there have been multiple instances where their patches inadvertently broke things) but it also underlines the fact that compatibility rather than security is their first priority... and this comes from a program manager at microsoft's security response center....
microsoft's security efforts are a failure, a farce, and the public has lost confidence in them... and not just a little bit of confidence either; the WMF incident back in december and now the new IE vulnerability just a few months later, both with wide adoption of 3rd party patches, indicates that this is a watershed event... confidence in microsoft's security efforts has crossed a threshold...
the worst thing, for microsoft at least, is that they're losing control over a captive market... 3rd party patches open the door for competition for their paid support program(s), as well as eat away at the leverage they have for getting people to upgrade by ending support for older versions of their products... ending support has a lot less meaning when other people are willing to pick up the slack...
microsoft talks a good game about security, i saw one of them talk about it at RSA2002, they go to great lengths, but they seriously underestimate the significance of risk when they leave the window of exposure open as long as they do while trying to make the perfect patch... when there's a serious exploit in the wild there should be no question of whether or not to release a patch out of cycle, it should be released as soon as it's made and refined and updated after the fact... so long as a seasoned expert at writing secure code is making the patch (rather than some green code monkey they're trying to train), any problems that might arise from a rushed patch are almost certainly going to be less severe than than the one it's supposed to fix... further, new vulnerabilities from a rushed patch would require additional time and effort from the attacker community to exploit so as long as the development of the patch continues after the initial release so that updates to the patch can be pushed out if needed...
Subscribe to:
Posts (Atom)