OSNews

Anon said: " I can't count how many times I have read weekly post about how new security holes have been found in OpenSSH, Apache or other Open Source software."

Quality and security are measures which only mean something when compared relatively to another.

There is no absolutely secure, therefore you must expect, that once a vulnerability is made known to the vendor, the vendor should do their utmost to close the Window of Exposure ( http://www.counterpane.com/window.html ) as soon as possible.

For example, with the lastest SAMBA vulnerability, once notified, the SAMBA developer owned up to the mistake and the SAMBA project released a patch within 48 hours.Redhat has already backported the patch into their distributions RPMs.

Meanwhile there are currently 14 KNOWN unpatched vulnerabilities in Microsoft's Internet Explorer ( http://www.pivx.com/larholm/unpatched/ )
Some DANGEROUSLY EXPLOITABLE have not been fixed in over a year ( http://security.greymagic.com/adv/gm002-ie/ ).

Other inherent vulnerabilities, such as the Shatter attack ( http://security.tombom.co.uk/moreshatter.html ), Microsoft has known about since 1994!
Even if the API/call flaw is inherently unfixable, that is plenty of time for Microsoft to implement a safer methord/systemcall/API, adapt it's own applications to use the safer methord and depreciate the unsafe API.

It also appears that Microsoft 's own implementation of SMB is vulnerable and Microsoft has known about it for over eight years ( http://developers.slashdot.org/comments.pl?sid=59960&cid=5681769 ), but Microsoft either choose not to, or cannot fix the problem themselves.

Microsoft is clearly not closing the vulnerabilities they are aware that exist in their products and services.
Even after Bill Gate's Email, Microsoft by choice, remains neither secure or trustworthy.

Microsoft's attitude towards the security of it's products, service and customers is abysmal.

From Jason Coombs' A response to Bruce Schneier on MS patch management and Sapphire ( http://www.securityfocus.com/archive/1/315158 )
Microsoft Baseline Security Analyzer (MBSA) and Microsoft's version of
HFNetChk both failed to detect the presence of the well-known vulnerability
in SQL Server exploited by Sapphire, which is one of the reasons so many
admins (both inside and outside MS) had failed to install the necessary
hotfix. MBSA and HFNetChk are Microsoft's official patch status verification
tools meant to be used by all owners of Windows server boxes
...
In addition to designing MBSA to avoid scanning for SQL Server
vulnerabilities, failing to update mssecure.xml reliably and in a timely
manner, deprecating HFNetChk by pushing the MBSA GUI as its preferred
replacement, and hiding the details of the technical limitations and
internal security assumptions made by design in Microsoft's security
analysis tools, Microsoft pushes Windows Update (windowsupdate.com) as a
safe and reliable way to keep Windows boxes up-to-date. Unfortunately,
Windows Update isn't designed to supply or verify the presence of SQL Server
hotfixes, either.

None of Microsoft's own hotfix/patch status scanning tools designed to prove
"baseline security" were able to help administrators avoid Sapphire. This
entire scenario, this comedy of errors, illustrates the security risk
created by any organization that pushes security around from department to
department, passing the buck and hoping that somebody else will know how to
deal with the problem. The result is a system so flawed that it borders on
the absurd.

Because of this continued inherent attatude to security, Microsoft's products and services should be considered UNSECURE by default.