I ran across this vulnerability report. The goal of which appears to be to show that Windows Server 2003 has fixed significantly fewer flaws than various other operating systems. Upon reading the report, the first thing that popped into my head was "But what about the things that aren't fixed?" There are quite a few reports like this, none of them really say much. We can safely say that any report is going to show that lots of things get fixed in operating systems that contain lots of things.
I wouldn't mind seeing an report about the various outstanding flaws in a given system. Such a report is likely impractical to produce, as it's a full time job to track outstanding flaws, but it would no doubt be useful. It's very easy to draw the shortsighted conclusion that the more flaws a vendor fixes, the more insecure their product is. It would make just as much sense to say that the fewer flaws a vendor fixes, the more outstanding things they are still vulnerable to.
Real world security
It's always easy to talk about how great new security innovations are which are currently included in things like the kernel, glibc, and gcc. The real test of these technologies isn't how many articles are written about how neat they are, it's real world examples. I found two of these examples this week.
SELinux blocks a Mambo exploit
In this example, we see that SELinux prevented a worm from spreading. This was the result of SELinux sandboxing the httpd process. There are a great many people who suggest the best way to run SELinux is to disable it. I suspect this article proves that SELinux works, and should be used.
Stack Protector blocked an rsync off by one error.
CVE-2007-4091 describes an off by one error in which a stack buffer ends up writing a single NULL byte ('\0') past the end of the character array. The location of this buffer could possibly result in an attacker taking over program execution. Stack Protector contains logic which places a "canary" on the stack which is then checked to ensure that nothing fishy is going on. The canary completely nullifies the potential to exploit this flaw.
Firefox 220.127.116.11 was released this week. Neither Fedora or Red Hat Enterprise Linux will see this version. Here is why.
This update fixes these two flaws:
MFSA 2007-27 Unescaped URIs passed to external programs MFSA 2007-26 Privilege escalation through chrome-loaded about:blank windows
The reason the Mozilla Foundation released this update was primarily to address MFSA 2007-27. This is a rather serious flaw regarding to how Firefox hands URIs to external helper programs. This flaw does not affect Linux as helper applications are launched in an understood and controlled manner. The other flaw, MFSA 2007-26, is a rather minor flaw that has been rated as being of moderate severity. It involves how certain Firefox extensions create new windows. In general this flaw is harmless and upstream wanted to fix it since it was a regression from the 18.104.22.168 update.
A lot happens behind the scenes anytime there is an update of Firefox, Thunderbird, and Seamonkey. Apart from a great deal of developer and QA time, this translates into lost time for users as well. Vast quantities of bandwith are consumed to download the updates, then the various plugins must be updated. It was decided that it would be a great disservice to the users to squander the available recourses for an update they don't need.
Obviously, if you run Firefox on Windows, you best get this update, as the flaw is rather serious there.
Hacking via IPS Signatures
An Intrusion Prevention System (IPS) is supposed to stop malicious attacks from ever happening. In general most security researchers worth their salt feel these systems are a waste of time and money. They fall into the classification of security theater, or something that doesn't actually make you more secure, it makes you think you are more secure.
An article on Dark Reading claims something that has been suspected, but unproved, for a very long time about IPS vendors. Their 0day vulnerability signatures, aren't very 0day. One of the ways IPS vendors try to add value is to include currently unknown vulnerabilities they discovered. The way this works is they acquire information about a security flaw, create an IPS signature for it, add the signature to their product, then tell the vendor. The article from Dark Reading suggests that attackers are using the signatures to figure out what the vulnerability is, then leveraging the fact that it's not fixed in the vendors product.
How this will be handled by various vendors is now a vary real question that needs to be addressed. We shall see where it goes.