kernel.org后攻击的可信度

Question

kernel.org的妥协对托管在站点Git存储库上的代码库的可信度有什么安全含义？今天的声明解释了160位哈希、站点镜像和开发工作的分布式特性所提供的缓解。考虑到主Git存储库的散列，这些再保证是否与它们的散列代码和典型用法/镜像同时存在，因为站点在检测之前已经被破坏了17天？最后，在这一活动的基础上可以提出哪些改进建议？

Answer 1

在Git的使用方面，软件和分布式特性在保护代码和检测恶意修改方面起了很大作用。首先，除非与相应的SHA-1哈希匹配，否则不能更改旧的提交。即使一次提交与某个SHA-1匹配，它也会影响子SHA-1散列，所以这是不可能的。任何比违约日期更早的事情都不能合理地改变，否则就会破坏存储库和同步。

提交可以在该17天内添加。因为时间戳是提交的SHA-1散列的一部分，所以我们可以缩小“可疑”提交的列表范围，方法是查看任何早于违约前的提交，或者是提交的子日期小于父日期的任何内容。如果您曾经尝试过在git中的提交到共享存储库之后修改它，那么您就会明白，很明显，某些历史性的东西被更改了。

由于包含完整历史记录的内核散列的完整副本分布非常广泛，并且总是通过遵循用户不知道的不能向后滚动的提交链增量更新，所以即使主机网站被破坏，内核源代码实际上也是非常安全的。

最后，因为只有有限数量的个人能够合法地提交内核，所以我们可以期望他们能够注意到他们不希望看到的对他们部分的任何更新。签名的人工控制(某种程度上是一种技术控制，但不是)在了解内容来源方面起着很大的作用。

总之，在Git中以一种未被察觉的方式损害内核源代码将是十年来最令人印象深刻的黑客之一。一个人将有一个更容易滑入代码通过适当的渠道，看起来无害，但是恶意的。

Answer 2

这个问题不应该叫做“kernel.org攻击前的可信度”吗？再想一想，我想这个问题已经回答了。:-)

我可能会花费我的大部分分析时间来决定我对他们是否确定最早的攻击日期有多确定。