Full Disclosure mailing list archives
Re: Two MSIE 6.0/7.0 NULL pointer crashes
From: mrx <mrx () propergander org uk>
Date: Thu, 21 Jan 2010 09:31:02 +0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michal Zalewski wrote:
Testing takes time. That's why both Microsoft and Mozilla test.Testing almost never legitimately takes months or years, unless the process is severely broken; contrary to the popular claims, personally, I have serious doubts that QA is a major bottleneck when it comes to security response - certainly not as often as portrayed. The generalization made earlier in this thread - that closed source projects are always bad when it comes to security response, while the open source community is inherently responsive - does not even deserve a proper rebuttal. I am cc:ed on quite a few open security bugs in major open source software - and when a problem is kept under wraps, it is not unheard of to wait 6-12 months for a fix. Both in the open source and in the closed source world, the real story is almost always that the security issues you report need to be prioritized against hundreds of other internally discovered security problems; and thousands of high-priority but non-security bugs that affect market adoption or annoy key customers. On top of this, many security changes may require significant rewrites that the vendor is hesitant to implement because of having no resources or no long-term plan to do so. In other words, in many cases, most of the waiting period is a prolonged no-op that may serves no legitimate function, and may be putting users at an unreasonable risk. Even without assuming malice on the side of the vendor, this demonstrates an inherent weakness of the "responsible disclosure" process (understood as accepting arbitrary vendor-provided disclosure timelines): while some vendors are quite willing to give security issues top priority, and will actually work to get things done - others may exploit the rhetoric to mask staffing problems or the inability to drive engineering decisions effectively. Cheers, /mz
Thank you for the insights Michal. I accept my comment was a little glib, however it has been my experience that open source vulnerabilities of this magnitude that are in the wild are usually fixed in a day or two by the OS community whereas large closed source developers can take weeks or longer to release a fix for such flaws. Perhaps this is due, at least in part, to the modularity and separation of function in OSS and being able to a personally identify the developer of a vulnerable OS project. Also a single person or small team can act more efficiently on known code. Where as in a large corporate closed software development environment where an application carries so many dependencies on evolving and legacy code, where the person responsible for introducing the vulnerability is not publicly identifiable can lead to all kinds of denial, excuses and buck passing. Perhaps I am a little naive, after all I am a novice in this field which I am not afraid to admit. But it seems to me with large closed source projects developed in commercial corporate environments the object of the exercise is to get product out first regardless of the quality of the released code. And only if a vulnerability is a threat to adoption of a product is that vulnerability dealt with in a timely fashion. regards mrx - -- Mankind's systems are white sticks tapping walls. Thanks Roy http://www.propergander.org.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBS1ge1rIvn8UFHWSmAQIJyQf+KXxLSS1/UOi0oRlFE3+5O9tMifKUMDMu qasl2DPQVxV3gj81D2J8Skzmv7ixgQpL7/kSprrX48XdhQjKvohEzaR32mJVrtba t3njHWaf0fEUWBkTajGmpVtDvn+dnC86Y6cFNs3W8bWeKFX1d5uBdlPDeoNQrtSL TPIqQPWX2zaEHDwZe2AD8Qi7RccBP5SQUy+ilmQJ/USiWI9DlFcXTf7OYT/Y4RGD t9a5w420YJQyrbCHWWd8WI0vrMGAYPb9oWJphrPrxaw7AvWqkwcQSA4EdMpEaPww YIrcH5XriNFy//A6Fpc6/4r9OUWEeEy3sZmG54gXahFWRl1rjc62aw== =eMUR -----END PGP SIGNATURE----- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: Two MSIE 6.0/7.0 NULL pointer crashes, (continued)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes ☣ frank^2 (Jan 20)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes Rohit Patnaik (Jan 21)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes Jeffrey Walton (Jan 22)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes Valdis . Kletnieks (Jan 23)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes Christian Sciberras (Jan 23)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes dramacrat (Jan 20)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes Jeffrey Walton (Jan 20)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes Dan Kaminsky (Jan 20)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes Michal Zalewski (Jan 20)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes mrx (Jan 21)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes Dan Kaminsky (Jan 21)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes Christian Sciberras (Jan 21)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes Jeffrey Walton (Jan 21)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes Pavel Kankovsky (Jan 23)
- Re: Two MSIE 6.0/7.0 NULL pointer crashes Dan Kaminsky (Jan 23)