当软件供应商进行补丁和发布建议时，需要公布多少细节？

Question

我感兴趣的是，社区的想法是什么详细提供的软件供应商，以及修复和安全咨询。

例如，假设某种严重的漏洞是私下引起供应商注意的。它是修正了它，一个新的发行版，补丁和发布了一个安全咨询出版。

在这个安全咨询中，您希望供应商披露多少信息？

在我看来，有两件事需要权衡：

1. 进入太多的细节，给黑色帽子世界的气味，关于缺陷的存在和如何找到它，谁可能比供应商的客户反应更快
2. 以透明的名义提供细节，客户想知道这件事到底有多严重

第一种担忧是有效的，还是.

Answer 1

做事情的“正常”方式是：

1. 不管是谁发现了这个漏洞，都会联系到供应商。
2. 供应商制作并发布修补程序，并以模糊但可怕的描述将其推向客户(“修复允许远程代码执行的缺陷”)。
3. 几周后，详细情况公布了。如果一切顺利，最初的发现者在与供应商完全一致的情况下发布该出版物，从而将应得的信用划归在内；供应商在自己的文档中添加到出版物详细信息的链接。

例如，与SSL相关的被称为“犯罪”的缺陷就是这样发生的:浏览器供应商提前几周收到警告，并推送补丁。偶尔，对某些人来说，这种模糊的描述在实际发布前几天就已经足够猜猜发生了什么了。舞蹈是一个微妙的问题，特别是开放源码软件，因为补丁源代码往往是相当揭示问题的确切性质。

这个问题的一个心理方面是，易受攻击的人是一群强硬的人，有时，如果他们觉得供应商的反应不够恰当或不够快，他们可能会以某种激烈的情感方式做出反应。软件供应商通常倾向于保守漏洞的秘密，但如果他们不得不接受发布，那么，至少他们真的更愿意得到一些预先警告。“预先警告的应得学分”是一种很有可能说服大多数捕虫者不要立即在公共渠道上利用漏洞的交易方式，因此软件供应商将支持这种“正常方式”。

最终，当尘埃落定时，所有的细节都应该公布，因为充分的披露是信任的重要基础。

Answer 2

我对此的主要观察是，如果有人能够编写利用代码来处理许多这样的缺陷，那么他们也很可能能够分析修补程序本身来识别缺陷。知道漏洞存在的细节，甚至知道该缺陷通常如何工作，并不一定能为实现它提供更多的帮助。

仍然有必要对系统进行分析，并确定如何实现利用。这是分析补丁正在改变什么并消除所有噪音所需的技能集，因此公开公开一些细节的风险可能并不坏，只要没有该技能集就无法进行有效的开发就足够了。

也就是说，这取决于漏洞的类型。例如，如果存在SQL注入漏洞，则攻击可能比缓冲区溢出容易得多。因此，该漏洞的性质也必须加以考虑。

关键是提供足够的信息，让用户了解他们的暴露情况，并采取适当的措施，同时也要确保您不会给聪明的攻击者提供更多关于如何实现有效攻击的细节，而不是补丁本身提供给他们的详细信息。