Comments on: Critical Vulnerability in Microsoft Metrics http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/ Thu, 19 Nov 2009 15:36:11 -0800 http://wordpress.org/?v=2.8.6 hourly 1 By: DonB http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/comment-page-1/#comment-15964 DonB Fri, 25 Jan 2008 12:12:24 +0000 http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/#comment-15964 "We’re not building fixes for our PR team, we’re building them for our users. Go ahead and count..." Hahaha.... “We’re not building fixes for our PR team, we’re building them for our users. Go ahead and count…”

Hahaha….

]]> By: abcd http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/comment-page-1/#comment-9624 abcd Tue, 18 Dec 2007 21:17:39 +0000 http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/#comment-9624 Please ! Keep it simple and don't play their game : They are not counting vulnerabilities. It's just a word game. Let me repeat : They are counting PATCHES and not VULNERABILITIES. It's THIS simple. Please read dictionary or wikip definitions if you don't believe me. Please read their "reports" by putting the right words, and you will see there is no meaning at ALL. And, oh... other words they mess with : "MS security chief" => "MS public-face-advertising-chief" "report" => "advertising paper". Please ! Keep it simple and don’t play their game : They are not counting vulnerabilities. It’s just a word game.

Let me repeat : They are counting PATCHES and not VULNERABILITIES. It’s THIS simple. Please read dictionary or wikip definitions if you don’t believe me.

Please read their “reports” by putting the right words, and you will see there is no meaning at ALL.

And, oh… other words they mess with : “MS security chief” => “MS public-face-advertising-chief”
“report” => “advertising paper”.

]]> By: Phil http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/comment-page-1/#comment-7893 Phil Tue, 04 Dec 2007 08:24:25 +0000 http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/#comment-7893 Luci, >>Of course, it’s so easy to find vulnerabilities in a binary, while, obviously, having the source code around can only make your life harder on this one. Actually I think you'll find plenty of serious researchers find it easier to see bugs in assembler rather than in C/C++, so raw binary or source code makes little difference. Luci,
>>Of course, it’s so easy to find vulnerabilities in a binary, while, obviously, having the source code around can only make your life harder on this one.

Actually I think you’ll find plenty of serious researchers find it easier to see bugs in assembler rather than in C/C++, so raw binary or source code makes little difference.

]]> By: Luci Stanescu http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/comment-page-1/#comment-7868 Luci Stanescu Mon, 03 Dec 2007 23:24:48 +0000 http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/#comment-7868 "Fixing them is one thing, preventing them from appearing in the first place is another." and "That remembers me of the 3rd dubest idea: http://www.ranum.com/security/computer_security/editorials/dumb/" Adopting a secure model is one thing. Creating something perfect is another. Either the author of those "dumb ideas" was exagerating or what I just read there is plain dumb. There is no such thing as "unhackable". Developers are human beings. While it may be hard to introduce great security flaws in something like cp, creating a perfect >10.000 line software is far from possible. As he puts it, I understand that we should spend about 200 hours writing a software and distribute it as soon as it compiles (and it must compile in the first shot, as we adopted a good model, right?). Why, for God's sake, would anyone want to test software? Oh, one more thing: don't you dare compare a network to cp. That would be just plain stupid. pd and Paul: I'm waiting for a paper describing the flawed model of Firefox and the perfect model of IE (oh, and I would really love to find out how you managed to do that). "I would argue (with no hard data to back me up of course) that the combination of hackers and security researchers reviewing Microsoft code probably beats the number and quality of eyes reviewing Firefox code, in which case more discovered bugs in IE would be the expected outcome surely?" Of course, it's so easy to find vulnerabilities in a binary, while, obviously, having the source code around can only make your life harder on this one. I wonder how many security experts Microsoft has reviewing IE... "With the larger code churn of a service pack, Microsoft can fix un-exploited vulnerabilities without having to worry as much about putting the rest of their users (including past OSes sometimes) at risk." How exactly can you use "un-exploited" there? What makes you think that some other people won't find the vulnerability independently? If you ask me, they are taking a huge risk if this is true... “Fixing them is one thing, preventing them from appearing in the first place is another.”
and
“That remembers me of the 3rd dubest idea:
http://www.ranum.com/security/computer_security/editorials/dumb/”

Adopting a secure model is one thing. Creating something perfect is another. Either the author of those “dumb ideas” was exagerating or what I just read there is plain dumb. There is no such thing as “unhackable”. Developers are human beings. While it may be hard to introduce great security flaws in something like cp, creating a perfect >10.000 line software is far from possible. As he puts it, I understand that we should spend about 200 hours writing a software and distribute it as soon as it compiles (and it must compile in the first shot, as we adopted a good model, right?). Why, for God’s sake, would anyone want to test software? Oh, one more thing: don’t you dare compare a network to cp. That would be just plain stupid.

pd and Paul:
I’m waiting for a paper describing the flawed model of Firefox and the perfect model of IE (oh, and I would really love to find out how you managed to do that).

“I would argue (with no hard data to back me up of course) that the combination of hackers and security researchers reviewing Microsoft code probably beats the number and quality of eyes reviewing Firefox code, in which case more discovered bugs in IE would be the expected outcome surely?”

Of course, it’s so easy to find vulnerabilities in a binary, while, obviously, having the source code around can only make your life harder on this one. I wonder how many security experts Microsoft has reviewing IE…

“With the larger code churn of a service pack, Microsoft can fix un-exploited vulnerabilities without having to worry as much about putting the rest of their users (including past OSes sometimes) at risk.”

How exactly can you use “un-exploited” there? What makes you think that some other people won’t find the vulnerability independently? If you ask me, they are taking a huge risk if this is true…

]]> By: GIles Jones http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/comment-page-1/#comment-7858 GIles Jones Mon, 03 Dec 2007 17:59:20 +0000 http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/#comment-7858 I don't see why Microsoft is so worried? it's not like anyone has made huge inroads into their desktop monopoly. A browser is just a gateway to the web. Until governments demand the removal of IE there is no danger of the computer illiterate masses downloading and installing Firefox. Open source projects are always going to be more transparent regarding bugs. Commercial organisations are likely to get more criticism or be embarrassed by public disclosure of internal defects. The whole argument about who writes better code, commercial organisations or the open source community is lost if commercial organisations reveal that their software is rushed and buggy. I don’t see why Microsoft is so worried? it’s not like anyone has made huge inroads into their desktop monopoly.

A browser is just a gateway to the web. Until governments demand the removal of IE there is no danger of the computer illiterate masses downloading and installing Firefox.

Open source projects are always going to be more transparent regarding bugs. Commercial organisations are likely to get more criticism or be embarrassed by public disclosure of internal defects.

The whole argument about who writes better code, commercial organisations or the open source community is lost if commercial organisations reveal that their software is rushed and buggy.

]]> By: Nicky http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/comment-page-1/#comment-7855 Nicky Mon, 03 Dec 2007 17:39:39 +0000 http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/#comment-7855 PR.. a form of survival when one fails to deliver. Oh well.. we love firefox just for that. PR.. a form of survival when one fails to deliver. Oh well.. we love firefox just for that.

]]> By: John http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/comment-page-1/#comment-7850 John Mon, 03 Dec 2007 16:53:14 +0000 http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/#comment-7850 The other major reason for pushing fixes to service packs is reverse engineering. If Microsoft issues a spot change for each vulnerability, it's fairly trivial to diff the binary before and after, discover what the vulnerability was, and exploit all un-updated machines. With the larger code churn of a service pack, Microsoft can fix un-exploited vulnerabilities without having to worry as much about putting the rest of their users (including past OSes sometimes) at risk. The other major reason for pushing fixes to service packs is reverse engineering. If Microsoft issues a spot change for each vulnerability, it’s fairly trivial to diff the binary before and after, discover what the vulnerability was, and exploit all un-updated machines. With the larger code churn of a service pack, Microsoft can fix un-exploited vulnerabilities without having to worry as much about putting the rest of their users (including past OSes sometimes) at risk.

]]> By: Peter Corcoran http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/comment-page-1/#comment-7848 Peter Corcoran Mon, 03 Dec 2007 15:28:33 +0000 http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/#comment-7848 Here Here! I completely agree. Here Here! I completely agree.

]]> By: Igor Bukanov http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/comment-page-1/#comment-7847 Igor Bukanov Mon, 03 Dec 2007 15:20:56 +0000 http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/#comment-7847 With a critical bugs discovered internally Mozilla also does not push the update immediately but rather includes it into the next scheduled update. Sometime it means that the patch is not released for over 2 months. This is not very different from MS policy that results in "a lot of time for an attacker to identify the same issue and exploit it to hurt users". With a critical bugs discovered internally Mozilla also does not push the update immediately but rather includes it into the next scheduled update. Sometime it means that the patch is not released for over 2 months. This is not very different from MS policy that results in “a lot of time for an attacker to identify the same issue and exploit it to hurt users”.

]]> By: Phil http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/comment-page-1/#comment-7846 Phil Mon, 03 Dec 2007 15:13:11 +0000 http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/#comment-7846 Of course a vendor will pick statistics that make them look good. That is of course why you prefer to focus on time to fix ;) But neither way gives a complete picture, so neither way should be dismissed out of hand. I happen to think Jeff does a fair job of transparency given his obviously biased position, and I've never seen him dismiss an alternate opinion without good solid data to back him up. And whilst I don't believe that 'hiding' security fixes in a new release is a good thing, I do understand the need to roll these things up whereever possible when you have to deal with an enterprise market as well as a home user one. As a home user I will happily enable autoupdate on my machine, so the frequency of patches has little impact on me. But as an enterprise administrator, the last thing I want is a new security patch to test and deploy every couple of days with no particular schedule. This is why Microsoft's patch Tuesday exists, and rolling patches into a service pack or new release is just an extension of this - balancing risk against convenience for me, the end customer. I would also be careful at trying to subtly promote the many eyes argument: 'Number of vulnerabilities identified is a function of how many bugs are present, but is probably more influenced by things like who is looking, and how good they are at finding security issues.' I would argue (with no hard data to back me up of course) that the combination of hackers and security researchers reviewing Microsoft code probably beats the number and quality of eyes reviewing Firefox code, in which case more discovered bugs in IE would be the expected outcome surely? Of course a vendor will pick statistics that make them look good. That is of course why you prefer to focus on time to fix ;) But neither way gives a complete picture, so neither way should be dismissed out of hand. I happen to think Jeff does a fair job of transparency given his obviously biased position, and I’ve never seen him dismiss an alternate opinion without good solid data to back him up.

And whilst I don’t believe that ‘hiding’ security fixes in a new release is a good thing, I do understand the need to roll these things up whereever possible when you have to deal with an enterprise market as well as a home user one. As a home user I will happily enable autoupdate on my machine, so the frequency of patches has little impact on me. But as an enterprise administrator, the last thing I want is a new security patch to test and deploy every couple of days with no particular schedule. This is why Microsoft’s patch Tuesday exists, and rolling patches into a service pack or new release is just an extension of this – balancing risk against convenience for me, the end customer.

I would also be careful at trying to subtly promote the many eyes argument:
‘Number of vulnerabilities identified is a function of how many bugs are present, but is probably more influenced by things like who is looking, and how good they are at finding security issues.’
I would argue (with no hard data to back me up of course) that the combination of hackers and security researchers reviewing Microsoft code probably beats the number and quality of eyes reviewing Firefox code, in which case more discovered bugs in IE would be the expected outcome surely?

]]>