如何以道德的方式披露安全漏洞？

#1 楼

您应该让开发人员私下知道，以便他们有机会对其进行修复。此后，如果并且当您公开此漏洞时，应该给开发人员足够的时间来解决该问题，并且让暴露给它的人有足够的时间来升级他们的系统。就个人而言，在大多数情况下，我将允许开发人员在安全公告中进行发布，而不是自己发布。至少，我将等待确认漏洞已修复的确认。如果您有时间可以访问源代码，则还可以提供一个补丁。

#2 楼

我个人认为，从道德角度出发，负责任的公开似乎是最好的方法，并且对于Dan Kaminsky揭示DNS缓存中毒漏洞的详细信息非常有用。但是，这在很大程度上取决于您正在处理的公司或集团，以及将影响的用户群。

#3 楼

@VirtuosiMedia在概述“负责任的披露”方面做得很好。

我想补充两点：烤的补丁。
如果供应商不理您或不理您，请继续尝试。但是，如果他们声称这不是漏洞，请继续发布。尽可能大声。如果他们答应修复但不解决，请尝试从他们那里得到答案，以及他们承诺的明确时间表。在某些时候，如果他们继续推迟，最终您可能要告诉他们无论如何都要发布-然后给他们一些时间进行实际修复（但简短而有限）。

#4 楼

这是一个复杂的话题。几年前，我参与了TLS重新协商错误的披露工作，并相信我，我们非常努力地做到“负责任”，但最终，我们成功地激怒了我们周围的每个人，并且（也许）延迟了修复程序的实际版本。并不是说供应商通知一定是不好的，只是说它很容易被鞭打和结清而造成的危害甚至是严重的甚至更严重。

在我们的案例中，采取了IETF的行动（RFC 5746）解决了这个问题，即使我们在泄漏之日准备了一份互联网草案，辩论和决定解决方案的实际工作又花了大约三个月的时间，直到真正开始才真正开始

无论如何，这并不是您的问题的答案，但这是我所知道的更有趣的披露故事之一。在我与Marsh Ray进行的2010年ShmooCon主题演讲中，有关该故事的更多信息。

#5 楼

通常，它取决于供应商的响应。好的做法是，安全研究人员将漏洞通知供应商，然后在谈话中您讨论该漏洞的poc / exploit发布条款。实际上，研究人员选择如何处理此漏洞-是否稍后发布。然后供应商发布补丁或新产品版本。也许。但是，经验显示-并非所有供应商都这么好。他们中的一些人在不通知最终用户和研究人员的情况下静默地修复了错误，而另一些人则更倾向于忽略研究人员。其他人甚至试图提起诉讼。这就是为什么有时匿名性是与未知供应商进行初始通信的首选方式。

我也要承认，这里有漏洞赏金奖励计划-由Google，Mozilla提供。此外，其他人购买漏洞-ZDI，iDefense，SNOsoft，即将到来的“漏洞利用中心”等。
因此，至少有三种方法可以通知供应商-通过在某些列表中发布漏洞信息或通过第三种方法直接通知供应商公司。

#6 楼

如果他们有公共问题跟踪程序，请查看是否可以使用“私人”或“安全”标签提交错误。
无论他们是否具有问题跟踪程序，请给security@公司名称发送电子邮件并告知他们。
如果他们没有及时做出回应（请参阅下面的Schneier文章中的“披露窗口”），那么您需要考虑更广泛地披露它。查找安全学者/专业人士潜伏的邮件列表，并询问他们如何向有问题的供应商报告问题。他们可能能够在组织中的正确位置进行介绍。
如果所有方法都失败了，请阅读Schneier的文章，并考虑完全公开将是问题的一部分还是解决方案的一部分。
布鲁斯·施耐尔（Bruce Schneier）提出了在某些情况下基于“成为解决方案的一部分，而不是问题的一部分”的标准进行全面披露的理由。绝对值得一读。

这是经典的“错误保密与完全公开”辩论。我之前在Crypto-Gram中已经写过有关它的内容。其他人也写过有关它的文章。这是一个复杂的问题，涉及到整个计算机安全方面的细微差别，值得再次讨论。
...
这种自由的信息流，包括描述和概念验证代码，对于安全研究。在过去的十年中，计算机安全方面的研究和开发蓬勃发展，其中大部分可以归因于全面披露运动。发布研究结果的能力-好的和坏的-可以为每个人提供更好的安全性。没有发布，安全社区就无法从彼此的错误中吸取教训。每个人都必须盲目地操作，不断犯同样的错误。如果我们要继续提高计算机和网络的安全性，则必须进行全面披露。第二，我相信会提前通知卖方。 CERT将此问题推到了极致，有时会给供应商一些时间来解决问题。
...
我喜欢“成为解决方案的一部分，而不是问题的一部分”的指标。研究安全性是解决方案的一部分。说服供应商解决问题是解决方案的一部分。播种恐惧是问题的一部分。向无知的青少年提供攻击工具是问题的一部分。