我们又来了-透视VSV00003¶
所以，如果你首先重读我两年前写的关于我们第一次 first major security hole.
从统计学上讲，从一个二进制数据点获取任何信息都是极其困难的。
如果某一事件发生在X年后，你所知道的就是这些，没有办法有意义地区分这是每千年一次的事件令人尴尬地提前到来，还是一年两次的事件流行地晚到来。
我们现在有两个数据点： VSV00001 发生在11年后， VSV00003 13年后 [1].
这使得我们可以将发现Varnish缓存中的主要安全问题的期望限制在“大约每十年3次” [2].
鉴于我使用Varnish缓存的目标之一是看看在自由/开源软件世界中用C语言进行系统编程的效果如何 [3] 尽管我们比自由/开源软件世界的大多数人做得更好，但这有点令人失望 [4].
野兽的本性¶
VSV00003是一个缓冲区溢出，这是一种错误，它可以通过许多不同的方式表现出来，但在这里它直接进入了 assert 语句，因此它“仅仅”是一个拒绝服务漏洞。
DoS当然已经足够糟糕了，但远没有远程代码执行或信息泄露漏洞那么糟糕。
这再次验证了我们使用断言散布源代码的策略，大约十分之一的源代码行包含断言，甚至更多，因此我们将断言留在生产代码中。
我真的希望更多的自由和开放源码软件项目能采用这种做法。
我们是怎么找到它的¶
这对我来说有点尴尬。
多年来，我一直在喃喃地说想要 "fuzz"[5] Varnish，看看会发生什么，但在待办事项清单上的许多其他项目中，它从未真正跃居榜首。
Varnish-Software的一名新员工需要一种方法来了解源代码，所以他做到了，并以太快的速度发现了这块金块。
向阿尔夫-安德烈·瓦拉致敬。
处理它¶
Varnish Software的Martin Grydeland一直是这个安全问题的高级牧马人，而我故意采取了不插手的立场，我没有理由后悔这个决定。
非常感谢马丁！
正如我在VSV00001的上下文中详细解释的那样，我们非常希望能够提供基于VCL的缓解，以便由于这样或那样的原因而无法立即更新的人仍然可以保护自己。
起初我们甚至认为这是不可能的，但告诉一位德国工程师……
UPLEX的尼尔斯·戈罗尔没有说 "Halten Sie Mein Bier…" ，但他确实立即产生了一个VCL解决方案，再次使用Inline-C功能来Frob通常是“这扇门后面没有用户可服务的部件”的东西。
太棒了，尼尔斯！
我们是不是找错人了？¶
可以说，像这样的活动是“重新计算路线”的好机会，我们需要回答的第一个问题是，我们是否找错了方向？
在现实世界中，瓦尼什每年不吐出一把CVE有关系吗？
我们花在防止这种情况上的大量时间会不会更好地用于扩展Varnish？
毫无疑问，Varnish缓存成功的部分原因在于它在很大程度上是“即烧即忘”。
我经常收到“新人”发来的一封电子邮件，他刚刚发现了一个运行了多年的Varnish实例，而公司里的每个人都不知道。
现在仍然有Varnish2.x和3.x版本，它们运行着繁重的工作负载，而不会对此感到困惑。
但这真的是一件好事吗？
丹·吉尔不这么认为，他认为所有的软件都应该有一个明确的失效日期，以防止网络空间以“网络安全超级基金网站”而告终。
到目前为止，我们的两大安全问题都是DoS漏洞，攻击一结束，Varnish就会恢复，但如果下一个是数据泄露问题呢？
当Varnish用户不习惯为他们的Varnish实例打补丁时，他们会注意到安全警告吗，或者他们会连续多年无意中运行易受攻击的代码吗？
当然，更新软件包从来没有这么简单过，在运行良好的安装中，它应该是自动发生的非事件。
在一个2019年8月总共有2004名CVE的世界里，我们(仍然)应该为那些“烧了就忘了”的人提供多少服务？
最后，我们必须问问自己，如果我们仍然每隔一年就面临一次重大的安全问题，那么我们在代码质量上所花费的所有努力是否值得？
我们将在下一次VDD上讨论这些和许多其他问题。
我们非常欢迎用户的意见。
phk
脚注