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] [day] [month] [year] [list]
From: dufresne at winternet.com (Ron DuFresne)
Subject: Re: it\'s all about timing

All these proposals for responsible vulnerability reporting have as a
major problem, the vendors first in my eyes.  I can't count the times I
see folks asking in various lists "how do I contact such&such vendor to
report an issue", and long ago quit counting the times I've seen
vulnerability reports in the various lists where the vendor had not
responded, or their response was like M$ tends to be, "we do not consider
this a vulnerability nor a serious issue" when in fact it is.  How many
times now has M$ changed it's vulnerability/security issues reporting
address/proceedures?  I think those finding and sicovering these issues
would be more willing to work within a responsible structure if the
vendors would adopt a responsible attitude and process on their end.
Afterall what the vendors recive is free information and debugging on
their product<s>/code, free research, and the man hours of countless
folks, which costs them nothing, no paychecks, no benefits to payout, not
even unenjoyment insurance, if they would act responsibly to begin
with.  Afterall, there was a reason full disclosure and the various lists
came to  be in the first place, frustration due to vendors not taking a
responsible attitude towards both the code/products they push to market as
well as their customers.

Thanks,

Ron DuFresne



On Fri, 2 Aug 2002, Steven M. Christey wrote:

>
> choose.a.username@...hmail.com said:
>
> >It is very unclear as to what it is that you are really after. Who are
> >these people "Vulnerability researchers", who's label is this?
>
> It's an RFPolicy-ism.  Alternate terms are "reporter" (which covers
> "bug hunters" and "people from the press") and "notifier" (which is
> probably more accurate than "researcher," because the notifier might
> not be the person who discovered the issue).  I'm leaning towards
> "notifier."
>
> >Are thes professionals now not adhereing to some suitable reporting
> >method where they do in fact alert the vendor in private, work with
> >that vendor in private, and then release the advisory? Is this not the
> >case already?
>
> Based on an informal study I've done of about 350 researcher reports
> from early 2002, approximately 50% of the vulnerabilities were
> released without notifying the vendor, and about 20% of those reports
> included full exploit code.  (NOTE: the data is presently incomplete;
> but I hope to publish a full report in the future).
>
> But even in the case where the vendor is notified ahead of time, one
> needs only to look at the recent HP/SnoSoft situation to see that
> there are different opinions on how disclosure should happen.  Going a
> little further back, the ISS/Apache situation also demonstrated a
> variety in how professionals handle vulnerability reporting.  We may
> agree on the general notion of "give vendors some warning," but when
> you get down to the nitty gritty details - like *how much* warning,
> and how much effort the researcher should make, and how the vendors
> should respond - suddenly you realize that there's a lot of variety.
>
> You speak of "harnessing" vulnerability researchers.  A number of
> people have said that the current RVDP draft asks too much of
> researchers, including Georgi Guninski and Rain Forest Puppy (and some
> vendors).  That feedback will be taken into account in the next
> version.
>
> In the meantime, the current RVDP draft already has a number of
> suggestions for vendors:
>
> 3.3.1 Vendor Responsibilities
>
>    1) The Vendor MUST make it as easy as possible for Reporters,
>    Coordinators, Customers, and the Security Community to notify the
>    Vendor of vulnerabilities.
>
> as well as:
>
>    3) The Vendor SHOULD ensure that its staff knows how to recognize a
>    reported security issue and direct it to the Security Response
>    Capability.  This recommendation applies to staff who provide support
>    online, over the telephone, in person, or through some other means by
>    which reporters may interact with the Vendor.
>
> as well as:
>
>    6) The Vendor MUST provide a facility for individuals or
>    organizations who are not Customers to report vulnerabilities.  The
>    Vendor SHOULD NOT require (1) an active technical support number, (2)
>    telephone access that is not toll-free, or (3) user registration for
>    a web site or other facility that would be used for reporting.
>
>
> If more vendors follow the recommendations in the current draft, it
> will be easier for people to report vulnerabilities to them, which I
> think is a good thing.
>
>
> >Or do you mean the one-off vulnerabilty report, the one that some
> >individiual stumbles upon and sends it off to the lists.
>
> If the one-off person knows about security-related mailing lists, then
> hopefully they'll know something of disclosure issues.
>
> >Are you trying to harness them? Do you think some standard setout on
> >what do do with the reporting is going to trickle down to the
> >individual man in the street and he's going to (a) know about it (b)
> >be bothered to follow the method if he did.
>
> If there is enough awareness of disclosure issues in the IT community,
> then hopefully this won't happen as much.  However, as you say, there
> will always be people who won't follow the disclosure guidelines.
>
> You may be surprised to learn that the RVDP draft specifically tells
> vendors that they should be prepared for such a situation:
>
>   3.3.1 Vendor Responsibilities
>
>      7) The Vendor SHOULD recognize that inexperienced or malicious
>      reporters may not use proper notification, and define its own
>      procedures for handling such cases.
>
>
> I've mentioned at least 4 vendor requirements from the current draft,
> which would make the notification process easier for researchers.
>
> >Is there then a third set out there that needs this guidence everyone
> >is hollering about?
>
> I think so, and that's the people who are somewhere in between - maybe
> they're not professionals, but maybe they like to do research for fun,
> to analyze the software they use themselves, to build a resume,
> whatever (and before someone misinterprets what I just said, I
> personally don't think that there's anything wrong with doing research
> for resume-building).  Sometimes, it seems that researchers start out
> by releasing advisories without notifying the vendor, then as they
> gain experience, they work with the vendor more and more.  But I don't
> have any hard numbers to back that up.  Indeed, the whole area of
> disclosure is woefully short of hard numbers.
>
> - Steve
> _______________________________________________
> Full-Disclosure - We believe in it.
> Full-Disclosure@...ts.netsys.com
> http://lists.netsys.com/mailman/listinfo/full-disclosure
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
	***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ