Slashdot Mirror

Lets say we have two products both with a dozen (12) security holes. In six month, one releases patches for 6 of the 12 problems and the other releases patches for 11 of the 12 problems. Which is the more secure product, the one with 6 problems still left unaddressed or the one with 1 problem still left unaddressed?

Where are you getting the number 6 for exploits of IE? What is the true number of exploits available for each browser? How many of those 6 IE exploits include the ones that Microsoft has not announced and has left wide open. For all the upcoming advisories from eEye Digital Security, not a single one is currently for Firefox. So, I don't care which one had to be patched more in the past. I do care about which one should have been patched over 100 days ago and wasn't!

Lets say we have two products both with a dozen (12) security holes. In six month, one releases patches for 6 of the 12 problems and the other releases patches for 11 of the 12 problems. Which is the more secure product, the one with 6 problems still left unaddressed or the one with 1 problem still left unaddressed?

Where are you getting the number 6 for exploits of IE? What is the true number of exploits available for each browser? How many of those 6 IE exploits include the ones that Microsoft has not announced and has left wide open. For all the upcoming advisories from eEye Digital Security, not a single one is currently for Firefox. So, I don't care which one had to be patched more in the past. I do care about which one should have been patched over 100 days ago and wasn't!

Here is a list of every currently exploitable problem in Microsoft products that a SINGLE company has found.

http://www.eeye.com/html/research/upcoming/index.h tml

They have currently been waiting 165 days for a patch for remote code execution.

Microsoft: We're so great that there is nothing to do this month! Oh, don't worry about those High Severity Remote Code Execution vulnerabilities.

Macromedia and Real Networks have been competing with Microsoft, but Microsoft is considerably ahead in being insecure.

http://www.eeye.com/html/research/upcoming/index.h tml

Looks like certain software companies sit on the issues for a long time (and are still sitting on them).

In their defense, most of the KNOWN viruses/worms/trojans are written after the public release of the patch when the less capable people can see the exploitable code.

Both platforms need some way of bootstrapping to install the initial classes and loading mechanisms. Java 1.0 used a trusted file path that gave full trust to any class stored on the path. Code on the system CLASSPATH was fully trusted, so problems occurred when untrusted code could be installed on the CLASSPATH [15]. Java 2 treats code found on the CLASSPATH as any other code, but maintains backwards compatibility by using the bootclasspath to identify completely trusted code necessary to bootstrap the class loader.

Check http://eeye.com/html/research/upcoming/index.html site for a short list of overdue fixes.

And that's just the vulnerabilities THEY reported.

its not in the wild its in the public domain now http://seclists.org/lists/pen-test/2005/Aug/0183.h tml anyone who wants the binary for the scanner check below

http://www.eeye.com/html/Research/Tools/exe/Retina UMPNP.exe

In similar vein, note that you have to fill in your email twice . A classic example of why "double opt-in" is utterly meaningless.

To be fair to M$, there isn't much they can do more than releasing a patch. Patches will always get quickly reverse engineered and exploits developed, but their Automatic update mechanism in XP SP2 is the best you can hope for amongst the uneducated masses.

What really annoys me is that they actually leave vulns unpatched for months. See eeye:
http://www.eeye.com/html/research/upcoming/index.h tml, there are unpatched IE holes more than 4 months old!

"Similar to the MSBlaster RPC DCOM worm that struck in August of last year, "Sasser" uses a public exploit for the LSA vulnerability in order to obtain a SYSTEM-level command shell on its victims."

"It does not appear that the worm has any function other than propagation (and crashing vulnerable machines as an unintentional side-effect)." emphasis mine

"This is a classic technique used by malware to run malicious executable when Windows starts."

1. Send zillions of emails containing enticing links.
2. Watch as zillions of sheeple open said links with Internet Exploder.
3. Ensure your site is equipped with the IE exploit du jour.
4. Install keylogger, steal identity.
5. ??? [obligatory, but unnecessary - why not spend this time in Zen-like meditation contemplating the nature of suffering?]
6. Open anonymous delivery address using stolen identity.
7. Visit any shopping site via r00ted Windows box and stolen credit card number.
8. Profit!

More seriously, why not go and tell the Internet Exploder people to get their house in order. If enough people complain then maybe they'll actually release a patch. Remember, they haven't released a patch for these vulnerabilities for NINETY-SEVEN DAYS.

That's not the end of the story - check this out! - OK, they aren't publicly disclosed proof-of-concepts but those jokers at Microsoft haven't patched a critical vulnerability for NINETY-SEVEN days!! Talk about pathetic.

Despite being repeatedly asked about them, the Internet Exploder team refuse to answer a simple question: Why have they not fixed their critical security vulnerabilities for over 90 days?

I know, I know, I must be new here. But it was a very short article, and right near the bottom it says this (bold text is mine):

"Once these things are discovered, there's a rush as everyone tries to fix the problem," Christen Krogh, Opera's vice president of engineering said.

Krogh also pointed out that Secunia had rated the vulnerability as "less critical."

"This could fool some users into giving out some data to a site that wouldn't otherwise be able to get that information. But it doesn't seem like the most important issue," Krogh said.

So what does this tell us?

- The folks somehow blaming Opera for this announcement obviously didn't read past the first couple of paragraphs of this very short article.

- The folks who are saying "JavaScript is bad" obviously didn't read... okay I'm sure they just saw the word "JavaScript" and went off from there anyway. Hey, guys, enjoy your static black text on white background pages - and we'll see you in the unemployment line. Any ideas on how to manipulate the DOM without JavaScript?

- While I agree MS shouldn't blow this off, they're probably still busy patching some of those more critical problems.

- Once again, end user education is probably the answer.

One of the better worm analysis papers I've read was "Reflections on Witty" by Nicholas Weaver and Dan Ellis (of MITRE), published in the June 2004 issue of ;login, the Usenix magazine.

Rather than a dissection of the worm itself, the authors give a detailed analysis of the author/attacker of Witty.

Some insights about the worm author that Weaver and Ellis proposed:

• he was a fairly proficient programmer - there were no significant bugs in the code of the worm, he knew how to program x86 assembly and access the Windows API, he implemented a stack-overflow attack, and most importantly, he constructed a payload that was malicious to the host, but didn't significantly slow the worm's spread.
• he was quite clever at what he did - randomly padded packet sizes, randomized the destinations and port numbers, and he seeded the worm (rather than start at a single location, the worm started out from 110 different victims) -- prior to this no one had significantly seeded their worms
• he wrote compact code, Witty consists of 177 x86 instructions in 474 bytes (the rest is the buffer overflow and padding); with 177 instructions, he was able to construct routines to cleanup from the overflow attack, seed the RNG, propagate the worm, and execute the malicious payload (Witty slowly overwrites disks on the infected hosts until the machine crashes)
• he worked quite fast; the stack overflow in the ISS BlackIce products was published on March 18, 2004. Witty was released on March 19, 2004, less than 48 hours after the security advisory was published by eEye; it is possible that he knew of the vulnerability when eEye notified ISS on March 8, 2004, but the paper goes into why this is unlikely
• he probably tested the worm before he released it (cf. the lack of major bugs); this combined with the fact that he seeded on 110 hosts, means that he had access to a wide array of compromised machines -- it probably means he has access to the "hacker underground", to gain access to these machines in such a short time frame

The authors' conclusion is somewhat alarming, they reason that Witty represents a new generation of virus/worm authors: motivated, skilled and malicious individuals who are experts at what they do.

Although eEyes' reports look a bit confusing (look at the "Vulerability is over" image at the bottom), I think according to this page http://www.eeye.com/html/research/upcoming/index.h tml there are 3 security vulnerabilities affecting IE and Outlook that allow remote code execution.
The oldest one is 60 days old now and still not fixed.

If by 'known' you mean public, then yes, you are right. However, there are no less than THREE unpatched remote exploits for IE which have been discovered. See:

http://www.eeye.com/html/research/upcoming/index.h tml

I do agree that the 'Firefox is more secure' meme was largely unfounded, but don't let MSFT off the hook so easily. Switch to Opera ;-)

They were already working on patching this, but it was stolen before they could finish and leaked to bugtraq with LIVE material in the exploit (it's not a proof of concept, folks!) and no explanation or advisory.

Reminder: Bugzilla blocks /. referers. Copy URL and paste in new to view. (Beware Slashcode's extra spaces.)

https://bugzilla.mozilla.org/show_bug.cgi?id=29269 1 %lt; Original security bug (probably still blocked to outsiders to prevent someone stealing it before mitigation)

https://bugzilla.mozilla.org/show_bug.cgi?id=29330 2 %lt; Duplicate (reported after leak)

They are going to release a 1.0.4 shortly, I gather.

Still more timely than most of Microsoft's advisories... despite their earlier announcement. http://www.eeye.com/html/research/upcoming/index.h tml

Both Linux and Windows servers can be secured very easily. The XP desktop might still have issues, but Win2k3 server is solid and secure.

Yeah right, please go look there http://www.eeye.com/html/research/advisories/AD200 50208.html
and stop the BS about 2003 being secure.

And I strongly disagree with what you say about a Windows server being easily secured. That is just not true. Even experts have a hard time doing it.
And given my experience with Win2003 servers (installed and administered by experts, not by me) or even netcraft, I call BS on your claim of it being stable.

A study comes out saying Windows is better than Linux? Question the results, Impugn the source and dig as deep as it takes to find some political or financial affiliation between them and Microsoft, no matter how assinine or inconsequential.

They compared Windows Server 2003 and Red Hat Enterprise Server 3 running databases, scripting engines and Web servers (Microsoft's on one, the open source Apache on the other).

The setups were hypothetical, however. Both were in the most basic configuration, an approach that some in the audience suggested may tilt the results in favor of Windows, which comes with more features.

Ford said the idea was to represent what an average system administrator may do, as opposed to a "wizard" who could take extra steps to provide plenty of security on a Linux setup, for instance.

Their criteria included the number of reported vulnerabilities and their severity, as well as the number of patches issued and days of risk -- the period from when a vulnerability is first reported to when a patch is issued.

On average, the Windows setup had just over 30 days of risk versus 71 days for the Red Hat setup, their study found.

So why did I chose Secunia? Well, they don't issue advisories, they simply reflect the vendor advisories, and in some instances "rumblings in the marketplace." There is a downside to the site too, as some vendors don't patch so they may look better on Secunia. However, both Microsoft and Apache have good advisory records, so the data is useful.

Perhaps they need to make that idea they had of spending a month just squashing bugs an annual occurrance instead of the one off PR exercise that it appears to have been. In fact, why stop at Microsoft; there are plenty of vendors that could do with adopting this kind of practice and not all of them are closed source either.

"The biggest challenge we need to face centres on the myth and reality. There are lots of myths out there as to what Linux can do. One myth we see is that Linux is more secure than Windows. Another is that there are no viruses for Linux," said McGrath.

"Who is accountable for the security of the Linux kernel? Does Red Hat, for example, take responsibility? It cannot, as it does not produce the Linux kernel. It produces one distribution of Linux.

"In Microsoft's world customers are confidant that we take responsibility. They know that they will get their upgrades and patches."

The credibility of Linux in the enterprise is beginning to suffer, according to McGrath, as companies complete trials and find the platform wanting.

I specifically said "bypass OS security" and you bring up this?
Office is not a part of the operating system. A vulnerability in Office is not a vulnerability in the OS. Office cannot bypass system security including the execute permission.

You've yet to show any exploits that will bypass system file ACLs, which is what you appear to have been referring to in an attempt to refute a execute deny ACL's effectiveness.
If that's not what you were talking about, you need to be more clear. The only security settings I mentioned were file ACLs; if you wanted to bring up something else, you should say so.

Yeah, I guess you are right; viruses could still spread across e-mail without needing any extra binary files when the client has a vulnerability. Still, preventing users from running arbitrary executables (at least the ones in the IE cache) would be helpful wouldn't it?

Regardless, all of these have been patched. 3 years ago. If your patches are up-to-date, these vulns are moot. Vulnerabilities and patches are hardly something Microsoft has a monopoly on.

And your post looks like a good outline to implement security on a Windows network for average users.

Just curious, how well is your system working? Do you still have any virus/malware infections? Do you use the default permissions or do you apply a security template, perhaps a custom one? Do you implement a deny-execute ACE for normal users where they have write access? It won't prevent everything by itself, but will provide another layer of security. How do you deal with (poorly designed) apps that require excessive permissions just to run?

Retina is another excellent tool, but pricey.

nmap and nessus are always in my 'bag'. use it on a regular basis.

That study, if it's the one I remember, used a flawed model for determining when to start the timer for bug fixes.

OSS bugs were termed live once they were informed about it while MS' were live once MS acknowledged the bug, often months after they were informed about it. Check out some Eeye data:

Upcoming advisories
Published advisories (click to see time to fix)

IBM is also bad, but Microsoft seems to be the worst, with most vulnerabilities taking well over 130 days to fix.

That study, if it's the one I remember, used a flawed model for determining when to start the timer for bug fixes.

OSS bugs were termed live once they were informed about it while MS' were live once MS acknowledged the bug, often months after they were informed about it. Check out some Eeye data:

Upcoming advisories
Published advisories (click to see time to fix)

IBM is also bad, but Microsoft seems to be the worst, with most vulnerabilities taking well over 130 days to fix.

I refer you to this webpage, where Microsoft has not fixed a known vulnerability in 123 days and counting. The others were not fixed in a timely fashion either. Show me an OSS vulnerability of similar criticality where it has taken that long.

I don't see many good reasons for a genuine _security_ product to _require_ ActiveX and scripting.

That requirement should give you a clue about whether it really is a security product or not.

I've seen this and I'll take my chances with keeping windows secure on my own thank you (with a little help from some *BSD firewalls etc).

Is the "security" product much better than the stuff it's supposed to protect? Is better enough to be worth paying for? Remember you'd have one more thing to keep patched - and it is likely the firewall runs as a privileged process and so firewall bugs could lead to attackers taking over the machine _via_ the firewall.

Something like this happened recently to ISS personal "firewall" and "IPS" products. Go look up the "witty" worm.

If possible keep your firewall separate from your machine. So what if your el-cheapo USD40 hardware firewall gets exploited - you are less likely to lose any personal and irreplaceable data (e.g. holiday/baby photos etc).

Microsoft does patch their OS quickly. The only problem is that many many people don't install the patches they provide. The vulnerability that CodeRed exploited was patched three months before the worm was released. The only reason it caused so many issues was because of incompetent Windows sysadmins.

Have you heard of this Outlook 2003 vulnerability (Script Execution Vulnerability) ?
It was discovered on May 17, but no patche today.
And this Internet Explorer exploit does no have a patche too.
If you look at this, you'll see that it took them more than 6 monts to release their patche on the LSAS vulnerability (used by Sasser).
Is that what you call "patch their OS quickly" ?

* Responsiveness: On average, Microsoft had a fix available 25 days after a security issue was publicly disclosed.

Anyone who remembers the hoo-hah after Eeye had two critical security flaws in windows sitting on it's "unfixed" page for 100+ days [1] will raise an eyebrow at this - this got a mention in Schneier's Cyptogram newsletter (the reference escapes me). It also depends on what they mean by "disclosed" - did eEye disclose it when they said there's something wrong? Or does a bug only become "disclosed" when people exploit it? (If the second one is true, linux bugs have mostly never been disclosed!)

If one devastating critical bug remains unfixed for six months [2], maybe the rest make up for it - but that's still six months you could be hosed in (and probably will be - think nimda). That's assuming that (for example) they aren't just equating the really critical bugs with the "someone can find the first letter of your name if you're wearing a hat and it's a full moon" type of bugs. Also what stevey (64018) said - bugs that aren't exploitable (or maybe even commonly felt) in Microsoft products aren't exposed. Perhaps even some bugs are fixed over service packs without notification (info, anyone?)

[1] "Two of eEye's most dangerous flaws [...] fixes are overdue by 94 and 66 days respectively."

[2] "200 Days to fix a Broken Windows" - According to the list, two other serious flaws have yet to be patched, and it's been five months since the software giant was first notified of them.

This is supposed to be a speedy response? I mean, let's look at Microsoft's record with eEye:
(Dates are dates of patch, not report)
April 13, 2004: Windows Expand-Down Data Segment Local Privilege Escalation - 144 Days
April 13, 2004: Windows Local Security Authority Service Remote Buffer Overflow - 188 Days
April 13, 2004: Microsoft DCOM RPC Memory Leak - 216 Days
April 13, 2004: Windows Metafile Heap Overflow - 164 Days
April 13, 2004: Windows VDM TIB Local Privilege Escalation - 64 Days
April 13, 2004: Microsoft DCOM RPC Race Condition - 216 Days (Yes, this is seperate)
February 10, 2004: Microsoft ASN.1 Library Length Overflow Heap Corruption - 200 Days
February 10, 2004: Microsoft ASN.1 Library Bit String Heap Corruption - 138 Days

And it goes on!

The Math: (144 + 188 + 216 + 164 + 64 + 216 + 200 + 138) / 8 = 166.25

Average 166 days for important vulnerabilities! I think their accountant missed something along the way...

You all know this already. Now go make sure someone in charge of a major corperation or something knows as well. =]

* Responsiveness: On average, Microsoft had a fix available 25 days after a security issue was publicly disclosed.

Anyone who remembers the hoo-hah after Eeye had two critical security flaws in windows sitting on it's "unfixed" page for 100+ days [1] will raise an eyebrow at this - this got a mention in Schneier's Cyptogram newsletter (the reference escapes me). It also depends on what they mean by "disclosed" - did eEye disclose it when they said there's something wrong? Or does a bug only become "disclosed" when people exploit it? (If the second one is true, linux bugs have mostly never been disclosed!)

If one devastating critical bug remains unfixed for six months [2], maybe the rest make up for it - but that's still six months you could be hosed in (and probably will be - think nimda). That's assuming that (for example) they aren't just equating the really critical bugs with the "someone can find the first letter of your name if you're wearing a hat and it's a full moon" type of bugs. Also what stevey (64018) said - bugs that aren't exploitable (or maybe even commonly felt) in Microsoft products aren't exposed. Perhaps even some bugs are fixed over service packs without notification (info, anyone?)

[1] "Two of eEye's most dangerous flaws [...] fixes are overdue by 94 and 66 days respectively."

[2] "200 Days to fix a Broken Windows" - According to the list, two other serious flaws have yet to be patched, and it's been five months since the software giant was first notified of them.

This is supposed to be a speedy response? I mean, let's look at Microsoft's record with eEye:
(Dates are dates of patch, not report)
April 13, 2004: Windows Expand-Down Data Segment Local Privilege Escalation - 144 Days
April 13, 2004: Windows Local Security Authority Service Remote Buffer Overflow - 188 Days
April 13, 2004: Microsoft DCOM RPC Memory Leak - 216 Days
April 13, 2004: Windows Metafile Heap Overflow - 164 Days
April 13, 2004: Windows VDM TIB Local Privilege Escalation - 64 Days
April 13, 2004: Microsoft DCOM RPC Race Condition - 216 Days (Yes, this is seperate)
February 10, 2004: Microsoft ASN.1 Library Length Overflow Heap Corruption - 200 Days
February 10, 2004: Microsoft ASN.1 Library Bit String Heap Corruption - 138 Days

And it goes on!

The Math: (144 + 188 + 216 + 164 + 64 + 216 + 200 + 138) / 8 = 166.25

Average 166 days for important vulnerabilities! I think their accountant missed something along the way...

You all know this already. Now go make sure someone in charge of a major corperation or something knows as well. =]

* Responsiveness: On average, Microsoft had a fix available 25 days after a security issue was publicly disclosed.

Anyone who remembers the hoo-hah after Eeye had two critical security flaws in windows sitting on it's "unfixed" page for 100+ days [1] will raise an eyebrow at this - this got a mention in Schneier's Cyptogram newsletter (the reference escapes me). It also depends on what they mean by "disclosed" - did eEye disclose it when they said there's something wrong? Or does a bug only become "disclosed" when people exploit it? (If the second one is true, linux bugs have mostly never been disclosed!)

If one devastating critical bug remains unfixed for six months [2], maybe the rest make up for it - but that's still six months you could be hosed in (and probably will be - think nimda). That's assuming that (for example) they aren't just equating the really critical bugs with the "someone can find the first letter of your name if you're wearing a hat and it's a full moon" type of bugs. Also what stevey (64018) said - bugs that aren't exploitable (or maybe even commonly felt) in Microsoft products aren't exposed. Perhaps even some bugs are fixed over service packs without notification (info, anyone?)

[1] "Two of eEye's most dangerous flaws [...] fixes are overdue by 94 and 66 days respectively."

[2] "200 Days to fix a Broken Windows" - According to the list, two other serious flaws have yet to be patched, and it's been five months since the software giant was first notified of them.

This is supposed to be a speedy response? I mean, let's look at Microsoft's record with eEye:
(Dates are dates of patch, not report)
April 13, 2004: Windows Expand-Down Data Segment Local Privilege Escalation - 144 Days
April 13, 2004: Windows Local Security Authority Service Remote Buffer Overflow - 188 Days
April 13, 2004: Microsoft DCOM RPC Memory Leak - 216 Days
April 13, 2004: Windows Metafile Heap Overflow - 164 Days
April 13, 2004: Windows VDM TIB Local Privilege Escalation - 64 Days
April 13, 2004: Microsoft DCOM RPC Race Condition - 216 Days (Yes, this is seperate)
February 10, 2004: Microsoft ASN.1 Library Length Overflow Heap Corruption - 200 Days
February 10, 2004: Microsoft ASN.1 Library Bit String Heap Corruption - 138 Days

And it goes on!

The Math: (144 + 188 + 216 + 164 + 64 + 216 + 200 + 138) / 8 = 166.25

Average 166 days for important vulnerabilities! I think their accountant missed something along the way...

You all know this already. Now go make sure someone in charge of a major corperation or something knows as well. =]

* Responsiveness: On average, Microsoft had a fix available 25 days after a security issue was publicly disclosed.

Anyone who remembers the hoo-hah after Eeye had two critical security flaws in windows sitting on it's "unfixed" page for 100+ days [1] will raise an eyebrow at this - this got a mention in Schneier's Cyptogram newsletter (the reference escapes me). It also depends on what they mean by "disclosed" - did eEye disclose it when they said there's something wrong? Or does a bug only become "disclosed" when people exploit it? (If the second one is true, linux bugs have mostly never been disclosed!)

If one devastating critical bug remains unfixed for six months [2], maybe the rest make up for it - but that's still six months you could be hosed in (and probably will be - think nimda). That's assuming that (for example) they aren't just equating the really critical bugs with the "someone can find the first letter of your name if you're wearing a hat and it's a full moon" type of bugs. Also what stevey (64018) said - bugs that aren't exploitable (or maybe even commonly felt) in Microsoft products aren't exposed. Perhaps even some bugs are fixed over service packs without notification (info, anyone?)

[1] "Two of eEye's most dangerous flaws [...] fixes are overdue by 94 and 66 days respectively."

[2] "200 Days to fix a Broken Windows" - According to the list, two other serious flaws have yet to be patched, and it's been five months since the software giant was first notified of them.

This is supposed to be a speedy response? I mean, let's look at Microsoft's record with eEye:
(Dates are dates of patch, not report)
April 13, 2004: Windows Expand-Down Data Segment Local Privilege Escalation - 144 Days
April 13, 2004: Windows Local Security Authority Service Remote Buffer Overflow - 188 Days
April 13, 2004: Microsoft DCOM RPC Memory Leak - 216 Days
April 13, 2004: Windows Metafile Heap Overflow - 164 Days
April 13, 2004: Windows VDM TIB Local Privilege Escalation - 64 Days
April 13, 2004: Microsoft DCOM RPC Race Condition - 216 Days (Yes, this is seperate)
February 10, 2004: Microsoft ASN.1 Library Length Overflow Heap Corruption - 200 Days
February 10, 2004: Microsoft ASN.1 Library Bit String Heap Corruption - 138 Days

And it goes on!

The Math: (144 + 188 + 216 + 164 + 64 + 216 + 200 + 138) / 8 = 166.25

Average 166 days for important vulnerabilities! I think their accountant missed something along the way...

You all know this already. Now go make sure someone in charge of a major corperation or something knows as well. =]

* Responsiveness: On average, Microsoft had a fix available 25 days after a security issue was publicly disclosed.

Anyone who remembers the hoo-hah after Eeye had two critical security flaws in windows sitting on it's "unfixed" page for 100+ days [1] will raise an eyebrow at this - this got a mention in Schneier's Cyptogram newsletter (the reference escapes me). It also depends on what they mean by "disclosed" - did eEye disclose it when they said there's something wrong? Or does a bug only become "disclosed" when people exploit it? (If the second one is true, linux bugs have mostly never been disclosed!)

If one devastating critical bug remains unfixed for six months [2], maybe the rest make up for it - but that's still six months you could be hosed in (and probably will be - think nimda). That's assuming that (for example) they aren't just equating the really critical bugs with the "someone can find the first letter of your name if you're wearing a hat and it's a full moon" type of bugs. Also what stevey (64018) said - bugs that aren't exploitable (or maybe even commonly felt) in Microsoft products aren't exposed. Perhaps even some bugs are fixed over service packs without notification (info, anyone?)

[1] "Two of eEye's most dangerous flaws [...] fixes are overdue by 94 and 66 days respectively."

[2] "200 Days to fix a Broken Windows" - According to the list, two other serious flaws have yet to be patched, and it's been five months since the software giant was first notified of them.

This is supposed to be a speedy response? I mean, let's look at Microsoft's record with eEye:
(Dates are dates of patch, not report)
April 13, 2004: Windows Expand-Down Data Segment Local Privilege Escalation - 144 Days
April 13, 2004: Windows Local Security Authority Service Remote Buffer Overflow - 188 Days
April 13, 2004: Microsoft DCOM RPC Memory Leak - 216 Days
April 13, 2004: Windows Metafile Heap Overflow - 164 Days
April 13, 2004: Windows VDM TIB Local Privilege Escalation - 64 Days
April 13, 2004: Microsoft DCOM RPC Race Condition - 216 Days (Yes, this is seperate)
February 10, 2004: Microsoft ASN.1 Library Length Overflow Heap Corruption - 200 Days
February 10, 2004: Microsoft ASN.1 Library Bit String Heap Corruption - 138 Days

And it goes on!

The Math: (144 + 188 + 216 + 164 + 64 + 216 + 200 + 138) / 8 = 166.25

Average 166 days for important vulnerabilities! I think their accountant missed something along the way...

You all know this already. Now go make sure someone in charge of a major corperation or something knows as well. =]

* Responsiveness: On average, Microsoft had a fix available 25 days after a security issue was publicly disclosed.

Anyone who remembers the hoo-hah after Eeye had two critical security flaws in windows sitting on it's "unfixed" page for 100+ days [1] will raise an eyebrow at this - this got a mention in Schneier's Cyptogram newsletter (the reference escapes me). It also depends on what they mean by "disclosed" - did eEye disclose it when they said there's something wrong? Or does a bug only become "disclosed" when people exploit it? (If the second one is true, linux bugs have mostly never been disclosed!)

If one devastating critical bug remains unfixed for six months [2], maybe the rest make up for it - but that's still six months you could be hosed in (and probably will be - think nimda). That's assuming that (for example) they aren't just equating the really critical bugs with the "someone can find the first letter of your name if you're wearing a hat and it's a full moon" type of bugs. Also what stevey (64018) said - bugs that aren't exploitable (or maybe even commonly felt) in Microsoft products aren't exposed. Perhaps even some bugs are fixed over service packs without notification (info, anyone?)

[1] "Two of eEye's most dangerous flaws [...] fixes are overdue by 94 and 66 days respectively."

[2] "200 Days to fix a Broken Windows" - According to the list, two other serious flaws have yet to be patched, and it's been five months since the software giant was first notified of them.

This is supposed to be a speedy response? I mean, let's look at Microsoft's record with eEye:
(Dates are dates of patch, not report)
April 13, 2004: Windows Expand-Down Data Segment Local Privilege Escalation - 144 Days
April 13, 2004: Windows Local Security Authority Service Remote Buffer Overflow - 188 Days
April 13, 2004: Microsoft DCOM RPC Memory Leak - 216 Days
April 13, 2004: Windows Metafile Heap Overflow - 164 Days
April 13, 2004: Windows VDM TIB Local Privilege Escalation - 64 Days
April 13, 2004: Microsoft DCOM RPC Race Condition - 216 Days (Yes, this is seperate)
February 10, 2004: Microsoft ASN.1 Library Length Overflow Heap Corruption - 200 Days
February 10, 2004: Microsoft ASN.1 Library Bit String Heap Corruption - 138 Days

And it goes on!

The Math: (144 + 188 + 216 + 164 + 64 + 216 + 200 + 138) / 8 = 166.25

Average 166 days for important vulnerabilities! I think their accountant missed something along the way...

You all know this already. Now go make sure someone in charge of a major corperation or something knows as well. =]

* Responsiveness: On average, Microsoft had a fix available 25 days after a security issue was publicly disclosed.

Anyone who remembers the hoo-hah after Eeye had two critical security flaws in windows sitting on it's "unfixed" page for 100+ days [1] will raise an eyebrow at this - this got a mention in Schneier's Cyptogram newsletter (the reference escapes me). It also depends on what they mean by "disclosed" - did eEye disclose it when they said there's something wrong? Or does a bug only become "disclosed" when people exploit it? (If the second one is true, linux bugs have mostly never been disclosed!)

If one devastating critical bug remains unfixed for six months [2], maybe the rest make up for it - but that's still six months you could be hosed in (and probably will be - think nimda). That's assuming that (for example) they aren't just equating the really critical bugs with the "someone can find the first letter of your name if you're wearing a hat and it's a full moon" type of bugs. Also what stevey (64018) said - bugs that aren't exploitable (or maybe even commonly felt) in Microsoft products aren't exposed. Perhaps even some bugs are fixed over service packs without notification (info, anyone?)

[1] "Two of eEye's most dangerous flaws [...] fixes are overdue by 94 and 66 days respectively."

[2] "200 Days to fix a Broken Windows" - According to the list, two other serious flaws have yet to be patched, and it's been five months since the software giant was first notified of them.

This is supposed to be a speedy response? I mean, let's look at Microsoft's record with eEye:
(Dates are dates of patch, not report)
April 13, 2004: Windows Expand-Down Data Segment Local Privilege Escalation - 144 Days
April 13, 2004: Windows Local Security Authority Service Remote Buffer Overflow - 188 Days
April 13, 2004: Microsoft DCOM RPC Memory Leak - 216 Days
April 13, 2004: Windows Metafile Heap Overflow - 164 Days
April 13, 2004: Windows VDM TIB Local Privilege Escalation - 64 Days
April 13, 2004: Microsoft DCOM RPC Race Condition - 216 Days (Yes, this is seperate)
February 10, 2004: Microsoft ASN.1 Library Length Overflow Heap Corruption - 200 Days
February 10, 2004: Microsoft ASN.1 Library Bit String Heap Corruption - 138 Days

And it goes on!

The Math: (144 + 188 + 216 + 164 + 64 + 216 + 200 + 138) / 8 = 166.25

Average 166 days for important vulnerabilities! I think their accountant missed something along the way...

You all know this already. Now go make sure someone in charge of a major corperation or something knows as well. =]

* Responsiveness: On average, Microsoft had a fix available 25 days after a security issue was publicly disclosed.

Anyone who remembers the hoo-hah after Eeye had two critical security flaws in windows sitting on it's "unfixed" page for 100+ days [1] will raise an eyebrow at this - this got a mention in Schneier's Cyptogram newsletter (the reference escapes me). It also depends on what they mean by "disclosed" - did eEye disclose it when they said there's something wrong? Or does a bug only become "disclosed" when people exploit it? (If the second one is true, linux bugs have mostly never been disclosed!)

If one devastating critical bug remains unfixed for six months [2], maybe the rest make up for it - but that's still six months you could be hosed in (and probably will be - think nimda). That's assuming that (for example) they aren't just equating the really critical bugs with the "someone can find the first letter of your name if you're wearing a hat and it's a full moon" type of bugs. Also what stevey (64018) said - bugs that aren't exploitable (or maybe even commonly felt) in Microsoft products aren't exposed. Perhaps even some bugs are fixed over service packs without notification (info, anyone?)

[1] "Two of eEye's most dangerous flaws [...] fixes are overdue by 94 and 66 days respectively."

[2] "200 Days to fix a Broken Windows" - According to the list, two other serious flaws have yet to be patched, and it's been five months since the software giant was first notified of them.

This is supposed to be a speedy response? I mean, let's look at Microsoft's record with eEye:
(Dates are dates of patch, not report)
April 13, 2004: Windows Expand-Down Data Segment Local Privilege Escalation - 144 Days
April 13, 2004: Windows Local Security Authority Service Remote Buffer Overflow - 188 Days
April 13, 2004: Microsoft DCOM RPC Memory Leak - 216 Days
April 13, 2004: Windows Metafile Heap Overflow - 164 Days
April 13, 2004: Windows VDM TIB Local Privilege Escalation - 64 Days
April 13, 2004: Microsoft DCOM RPC Race Condition - 216 Days (Yes, this is seperate)
February 10, 2004: Microsoft ASN.1 Library Length Overflow Heap Corruption - 200 Days
February 10, 2004: Microsoft ASN.1 Library Bit String Heap Corruption - 138 Days

And it goes on!

The Math: (144 + 188 + 216 + 164 + 64 + 216 + 200 + 138) / 8 = 166.25

Average 166 days for important vulnerabilities! I think their accountant missed something along the way...

You all know this already. Now go make sure someone in charge of a major corperation or something knows as well. =]

* Responsiveness: On average, Microsoft had a fix available 25 days after a security issue was publicly disclosed.

Anyone who remembers the hoo-hah after Eeye had two critical security flaws in windows sitting on it's "unfixed" page for 100+ days [1] will raise an eyebrow at this - this got a mention in Schneier's Cyptogram newsletter (the reference escapes me). It also depends on what they mean by "disclosed" - did eEye disclose it when they said there's something wrong? Or does a bug only become "disclosed" when people exploit it? (If the second one is true, linux bugs have mostly never been disclosed!)

If one devastating critical bug remains unfixed for six months [2], maybe the rest make up for it - but that's still six months you could be hosed in (and probably will be - think nimda). That's assuming that (for example) they aren't just equating the really critical bugs with the "someone can find the first letter of your name if you're wearing a hat and it's a full moon" type of bugs. Also what stevey (64018) said - bugs that aren't exploitable (or maybe even commonly felt) in Microsoft products aren't exposed. Perhaps even some bugs are fixed over service packs without notification (info, anyone?)

[1] "Two of eEye's most dangerous flaws [...] fixes are overdue by 94 and 66 days respectively."

[2] "200 Days to fix a Broken Windows" - According to the list, two other serious flaws have yet to be patched, and it's been five months since the software giant was first notified of them.

This is supposed to be a speedy response? I mean, let's look at Microsoft's record with eEye:
(Dates are dates of patch, not report)
April 13, 2004: Windows Expand-Down Data Segment Local Privilege Escalation - 144 Days
April 13, 2004: Windows Local Security Authority Service Remote Buffer Overflow - 188 Days
April 13, 2004: Microsoft DCOM RPC Memory Leak - 216 Days
April 13, 2004: Windows Metafile Heap Overflow - 164 Days
April 13, 2004: Windows VDM TIB Local Privilege Escalation - 64 Days
April 13, 2004: Microsoft DCOM RPC Race Condition - 216 Days (Yes, this is seperate)
February 10, 2004: Microsoft ASN.1 Library Length Overflow Heap Corruption - 200 Days
February 10, 2004: Microsoft ASN.1 Library Bit String Heap Corruption - 138 Days

And it goes on!

The Math: (144 + 188 + 216 + 164 + 64 + 216 + 200 + 138) / 8 = 166.25

Average 166 days for important vulnerabilities! I think their accountant missed something along the way...

You all know this already. Now go make sure someone in charge of a major corperation or something knows as well. =]

So 25 days, eh? Lets see what eEye lists in their upcoming advisories page... mmm Looks that Microsoft has closed some old advisories now, some months ago they had a very long list with very critical, remote vulnerabilities known for 6 months or more.

I havent seen a flash/shockwave security hole yet!

I have.

Thus the 5th generation of the 5th generation chip would have been kind of dumb.

Some of us use Mac OS X.

No Apple doesn't have any security problems.
Let's see within the last week they have closed at least two exploitable buffer overrun holes.
Of course Apple doesn't call them that. Instead they use euphemism.
"AppleFileServer: Fixes CAN-2004-0430 to improve the handling of long passwords."
Now go and read atstake.
Or, "QuickTime 6.5.1: Fixes CAN-2004-0431 where playing a malformed .mov (movie) file could cause QuickTime to terminate."
Now go and read eeye.
No problems at all.

I read a while ago that 0-day exploits on Windows are mostly unheard of, while most viruses seem to come out a few weeks AFTER Microsoft has issued a patch, because the virus-writers wait for a patch to disassemble it and learn how to exploit the weakness, which is easier to do that figuring out how to exploit the vulnerability.

I think that enought details about the vulnerability help more than a patch do disassemble.
MS say this to give a reason why they take so much time to release their patchs.

This hole was patched by Microsoft, when? A few weeks ago...

Yes, it was patched a few weeks ago. But if you look on this page, you'll see that eeye reported this problem to MS on October 8, 2003.
However they waited for MS to release a patch to give more details about it.
But there was people aware of this for a very long time ...

eeye.com advisory

It was fixed in a seperate Quicktime update released last friday:

http://www.macsecurity.org/node.php?id=141

It was fast for me :)

reference

I don't buy for a minute that 1) Microsoft releases patches faster or 2) that Microsoft even gives a damn about security, except for the black eye it gives them.

Microsoft, until recently, refused to listen to security experts who reccomend that OSes ship with services turned off by default. They have started to move in the right direction, with server 2003, but they are not there yet.

The Microsoft model essentially requires users to run as Administrator. Many 3rd party applications make the assumption that the user is Administrator, and won't run properly in a less privileged account. Microsoft has even made some apps which have the same requirements.

Microsoft's software is very layered, with many higher level functions relying on lower level layers. Outlook, and its relationship to to Internet Explorer is a good example. Bugs in IE (and you know there are lots of them) are frequently exploited by email worms. The time and effort just have not been put in by Microsoft to ensure that the lower layers of their architecture are secure. If the foundation is full of holes, there's no way to secure what's built on top.

OS X is a very good example of how to do security correctly. Users run as regular users, rather than as a privileged account. Some users are allowed to execute commands as root, via a sudo like mechanism (or using sudo from the command line), but it's an explicit step which must be taken by the user.

The notion that Apple is just for ignorent users is just absurd.