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>] [day] [month] [year] [list]
From: choose.a.username at hushmail.com (choose.a.username@...hmail.com)
Subject: Re: it\'s all about timing

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Having just read that article, seems nothing more like guess work.

"security advisory"
"vulnerability researchers"

What are the definitions for these?

Most of the time the vendor discounts a finding as being nothing more than a bug. No security implications. Then someone else takes it and manages to do something with it that does have security implications. Then again, what is the definition of "security". For a vulnerability researcher, unless this is now a trade and a recognised job title with certification from some "school", who or what exactly is that?

Joe Six-Pack installs a piece of software, he finds that pressing 1,2,3 on the key board at the same time deletes his hard drive. Thinks that's mighty unusual. Tells Joe 12-Pack, who tells him there is some mailing list you can send bugs to called bugtraq, so he posts it there. Knows nothing about anything. Certainly isn't a "vulnerability researcher" and certainly hasn't posted a "security advisory". Doesn't know what he has and doesn't know what he is doing. Is the vendor going to come after them and sue them?

Then on the other hand, you have some major vendors who go out of their way to discount what a some else finds as being nothing more than a "bug", that someone else follows the procedures, creates what they think is a  ""security advisory" and nothing gets fixed. A series of insurmountable hurdles or mitigating factors make it a bug and not a security matter at all. Hurdles like being enticed to visit websites on the internet or being enticed to click on links in emails. Someone else may take that publicised info and re-work it so that the hurdles are overcome, it may be a succession of 10 individuals inputting each one step closer. Should all this be funnelled to the vendor when they've already dismissed the original as nothing more than bug?

Two bad examples but someone is going to have to define what a vulnerability is, what a security advisory is and what vulnerability researchers are.



On Thu, 1 Aug 2002 01:45:46 -0400 (EDT), full-disclosure@...ts.netsys.com wrote:
>The Responsible Disclosure Process draft specifically allows for
>researchers to release vulnerability information if the vendor is not
>sufficiently responsive.  Some people may disagree with the delay of
>30 days between initial notification and release, but I don't think
>there are good stats on how long it really takes vendors to fully
>address vulnerability reports - open or closed source, freeware or
>commercial.  Let's take a recent example - how much coordination had
>to happen for the zlib vulnerability?  It seems reasonable to assume
>that it took more than a day.  And the controversial "grace period"
>has the interesting distinction of being used by both Microsoft and
>Theo de Raadt.
>
>Researchers can help to shed light in this area by publishing
>disclosure histories along with their advisories.  (By the way, vendor
>advisories rarely include such information.)
>
>While the response to the proposal focused almost exclusively on how
>it impacts researchers, it lays out a number of requirements for
>vendors, primarily that they (a) make it easy for people to file
>vulnerability reports, (b) be responsive to incoming vulnerability
>reports, and (c) address the issues within a reasonable amount of
>time.
>
>IMHO, it makes a stronger impression when someone releases a security
>advisory with an extensive disclosure history that says how much they
>tried to resolve the issue with the vendor, before they released.
>
>Those who are interested in the legal aspects of "responsible
>disclosure" are encouraged to read the article by Mark Rasch at
>http://online.securityfocus.com/columnists/66.  The article basically
>says that the adoption of community standards could protect
>researchers who disclose issues responsibly, while it could also help
>vendors who seek legal recourse against researchers who are not
>responsible (for some definition of "responsible").  The former could
>happen with a community standard.  The latter may already be happening
>without one.
>
>This email is my personal opinion, not my employer's.
>
>- Steve
>(co-author of the aforementioned Responsible Disclosure proposal,
>which is presently quiet but not dead, but will always be subject to
>public feedback)
>_______________________________________________
>Full-Disclosure - We believe in it.
>Full-Disclosure@...ts.netsys.com
>http://lists.netsys.com/mailman/listinfo/full-disclosure
>

-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wmYEARECACYFAj1OsE8fHGNob29zZS5hLnVzZXJuYW1lQGh1c2htYWlsLmNvbQAKCRDT
5JkCl0iMkKceAKCdna411CiJdVUoKLwRZYnTu9/1bwCfRTzt0fbS/v4m+nDsg/cHORRe
/OA=
=DvzJ
-----END PGP SIGNATURE-----


Communicate in total privacy.
Get your free encrypted email at https://www.hushmail.com/?l=2

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ