Get best of the week

现在是重新考虑OpenBSD安全性的时候了

OpenBSD被定位为安全的操作系统。但是，在过去的几个月中，系统中发现了许多漏洞。当然，这没有什么特别的。尽管某些漏洞非常少见。您甚至可以说批评。OpenBSD开发人员有一些有关如何确保安全性的准则。这是其中两个：

  • 避免错误；
  • 最小化错误风险。

并非所有人都同意这些原则足以构建安全的系统。在我看来，研究OpenBSD方法是否有效或最初注定要失败是有意义的。

为了说明，我没有选择全部，而是仅选择了一些有趣的错误，这些错误与我们的对话主题不谋而合。

libc认证


auth 函数运行辅助程序而无需进行argv检查。报告。补丁。

这是一个非常简单的错误，但是在代码审查期间似乎似乎不太明显。在我看来，部分原因是有些混乱是由谁来负责检查输入数据。您可以调用所涉及的三个组件中的每个组件：程序，库或login_passwd-可以合理地假设有人在检查。最后，我认为该库被判有罪，因为出现了一个补丁对她而言，但是就我个人而言，乍一看它的代码似乎并没有错。

故事中更有趣的部分是，即使提到了libc错误，login_passwd函数如果不是另一个错误，我也不会因此受到攻击。在2001年，login_passwd被重写以支持kerberos，也许那是他们引入错误的真正原因的时候。请求-响应类型身份验证商品（如s / key系统中的内容）返回经过身份验证的状态，而不是静默状态。多年后，删除了kerberos代码，但保留了支持它的部分代码以及所引入的错误。

如果彻底清除了kerberos代码，身份验证错误将仍然存在（argv解析还有其他一些相关问题），但其效果肯定会大大降低。

在安全上下文中正确解析argv并不容易。许多逻辑提示和方法在这里不起作用。我只会注意到此漏洞在关于Unix / Linux / POSIX上文件名问题的另一讨论，尽管前导减号（连字符）并未真正引用文件名。

搜搜


尚未 从ld.so代码中删除不良的环境变量。报告。补丁。

像是内存错误。但不是。此处的错误是将一项操作的成功-拆分环境变量-与删除该变量相关联。非常自信。

当然，各种类型系统的支持者将确保他们将以正确的顺序处理这些操作，但事实并非如此。由于缺少错误处理或内存分配错误仍然不可见，因此C代码没有崩溃。

ftp


ftp跟随重定向到本地文件。报告。补丁。

长期以来，NetBSD ftp重定向错误一直是不受控制的功能的典型示例。这里再次出现相同的错误（不幸的是，后果不大）！伙计们，好，坐在家里。不要在程序中添加额外的功能。

来自的smtpd


smtpd无法检查某些发件人地址。报告。补丁。评论。

我认为在Gilles的评论中已经说了一切，但我会提醒大家背景。很久以前，所有邮件都为每个用户本地存储在/ var / mail中在mbox文件中。这不是很酷，因为如果在mda传送新邮件时mua删除电子邮件，则可能会造成损坏（更不用说其他问题，例如扭曲发件人字段）。因此，mbox文件需要被锁定。但是锁定网络文件系统不能可靠地工作。因此，我们使用锁定文件代替锁定。但是，您需要就特定的阻止协议达成协议，因为用户拥有mbox文件，而根目录本身拥有目录。因此，为了实际修改mbox文件，您需要每次运行setuid帮助程序函数。好吧，这是第一个问题。过去的另一个遗迹是mda设置，它不仅可以用作程序，还可以用作Shell管道。人们开出类似spam-assassin | mail.mda而且你不能仅仅将其传递下去execve()。

过去有很多困难。而且，不幸的是，这个有问题的代码不能简单地被替换。电子邮件已经使用了很长时间，并且在此基础上构建了非常复杂的系统和工作流程，因此仅剪切一段代码并粘贴新代码是非常困难的。尽管特权隔离的级别不同，但根级父进程仍然严重依赖其特权较低的子进程。他将执行将收到的命令和参数。

避免这种情况就像切换到maildir存储格式一样简单，但是它需要在许多地方进行各种更改。标准Mua 邮件不了解此格式。对于我来说，mbox的寿命已经很长了，但是它仍然适合许多人，并且更新过程可能不是完全透明的，并且不会自动运行。

smtpd阅读


在smtpd范围之外进行读取可用于执行命令。报告。补丁。

这确实是一个内存安全问题。通过发送一些有趣的状态栏，远程smtp服务器可以将命令注入到smtpd队列中以便执行。当电子邮件排队等待重新发送时，smtpd将一些目标信息添加到标头中，以知道要执行哪个命令（请参见上文）。这种攻击类似于http请求的“走私”。如果您可以在标头中生成带有意外命令的“堆填”，则当您尝试重新发送时，smtpd将执行它们。

如上所述，问题之一是smtpd的最敏感部分过于靠近攻击面。在我看来，真正的问题是smtpd在电子邮件数据中存储了自己的元数据。因此，解析同步攻击成为可能。如果来自服务器的引用响应与传递说明完全独立于文件存储，则在边界之外进行读取不会有太大危害。

这个漏洞似乎向我表明，因为在这里我们看到将数据与不同信任级别混合在一起的危险。从未讨论过这种危险。她肯定是。

发现


当然，结论从一开始就很明确，但是无论如何我们都会谈论它。

我认为其中一些错误有助于说明删除过时的接口和降低代码复杂性等原则对于安全性至关重要。在大多数情况下，失败的发生是由于这些原则没有被遵循到最后，而不是因为这些原则本身被宠坏了或站不住脚。有些事情已经消失了，但是我不同意开发人员需要某种超人的警惕。给出无用的建议很容易，例如要小心，不要犯错误和git gud [s语游戏玩家表达的意思是“变得好”，也就是说，“变得更好，很快就好”-大约。跨]。但是我认为OpenBSD有更严重的问题。

即使是OpenBSD，也可能出于实用性的考虑而冒着安全风险。这就是为什么一些过时的项目长时间未进行修改的原因。因此，也许的教训是，应该始终遵循有效的原则，而不仅仅是在方便时。尽管通常很难做出正确的选择。

仅由于架构问题超出了原始错误的范围，三个最严重的漏洞auth和两个smtpd或多或少适合于利用。它们应该只是微小的缺陷，这些缺陷表明在一个受良好保护的系统中，不必争取完美的代码，也就是说，允许微小的错误-并且它们不影响安全性。 ,，以抽象形式识别设计缺陷可能很困难。而且，系统的所有部分都单独受到保护，但如果将它们组合在一起，则可能会出现弱点。

特权分离是OpenBSD安全性的关键组成部分，它基于进程间通信。仔细查看损坏的过程可能引起的问题是有意义的。受保护的浏览器正在日益加强保护并阻止攻击。特别是，必须保护smtpd免受网络任务中的内存损坏。但是他能够轻松地控制父母的过程令人震惊。

使用更安全的语言只能防止一个错误。是的，可能有某种程序习惯用法，在某些情况下，如果您虔诚地坚持下去，它会有所帮助。但是我不确定默认情况下每个程序员都可以正确编码所有对应的不变式。

编写邮件服务器是一项棘手的工作。尤其是当旧框架使您收紧时。


More articles:


All Articles