lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 20 Jan 2010 16:53:21 -0800
From: Michal Zalewski <lcamtuf@...edump.cx>
To: Dan Kaminsky <dan@...para.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Two MSIE 6.0/7.0 NULL pointer crashes

> 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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ