full-disclosure - it's all about timing

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]

Message-ID: <200208012016.QAA18371@linus.mitre.org>
From: coley at linus.mitre.org (Steven M. Christey)
Subject: it's all about timing

>	I.	Discoverer reports the problem to the vendor via
>		quiet channels;
>		A.	Vendor responds within three business days[2]
>			and dialogue on vulnerability is opened, or;

As a point of comparison, this is shorter than RFPolicy 2.0's
recommendations ("5 working days") and the Responsible Disclosure
draft ("7 calendar days" - which covers any 5 working days, which vary
depending on what country you're in, and allows for holidays.  We
would have chosen "5 business days," except it varies so much across
different countries.)

What happens if you think you've given the vendor 3 business days, but
2 of them was their country's "weekend," and the other day was a
national holiday?

>		B.	Vendor does not respond within three business
>			days and full disclosure occurs immediately, or;

The responsible disclosure draft allows for disclosure if the
researcher can't find the appropriate contact point, or if a human
does not respond (though it recommends involving a coordinator).

It also explicitly says that vendors should respond to the initial
report within 7 calendar days.

>	II.	If vendor responds per conditions as outlined in Section I,
>		Item A, then Discoverer and Vendor are at liberty to
>		set a timeline considered reasonable by both parties
>		(factoring in severity of vulnerability and likelihood
>		that vulnerability is already being actively exploited).

It seems that often, there is either (a) disagreement between
Discoverer and Vendor, or (b) they each have different expectations,
and those expectations are not part of the communication.  Also,
keeping open communication channels seems to be important; both
RFPolicy 2.0 and the RDVP draft both recommend that all parties
maintain regular communication.

>All bets are off if the vulnerability is discovered via a HoneyPot.
>Such a situation means that the exploit is in the wild and attackers
>already have full knowledge of attack methodology.

There seems to be general agreement in this area, although the RDVP
draft did not address this (an oversight).

- Steve