LWN：在email里面伪造另一封email！

关注了就能看到更多这么棒的文章哦～

Smuggling email inside of email

By Jake Edge
January 3, 2024
ChatGPT translation
https://lwn.net/Articles/956533/

通常情况下在发现新漏洞并与受影响方协调进行发布时，会在一个合适的时机进行公告，比如通常不会在年底假期前夕进行。然而，SMTP Smuggling漏洞的公告却没有按这个来，而是于 12 月 18 日发布。这在一些管理员可能不愿更新的情况下会让他们很不愉快，但对一些事先完全不知道漏洞的项目来说，情况更加棘手，尽管这个问题已经明确知道会影响到几个开源邮件服务（mailers）。

发现和披露

漏洞是由SEC Consult的 Timo Longin 于六月份发现的；该公司在七月份联系了三家受影响的供应商，GMX、Microsoft 和 Cisco。GMX 在八月修复了该问题，Microsoft 在十月修复，但 Cisco 回应称“这里所说的漏洞只是软件的一个特性，而不是 bug 或漏洞”。这导致 SEC Consult 联系了CERT Coordination Center (CERT/CC) 寻求进一步的帮助，使用了 Vulnerability Information and Coordination Environment (VINCE) 工具：

我们在那提交了所有的研究细节并向相关的供应商解释了这个 issue。收到了 Cisco 的反馈，他们认为我们确认出来的研究结果并非一个漏洞，而是软件的一项特性，并且他们将不会更改默认配置，也不会通知他们的客户。其他供应商在 VINCE 中没有回应，但已由 CERT/CC 联系到了。

根据这个反馈，以及通过 CERT/CC VINCE 平台将多个其他供应商包括在讨论中而未收到反对意见，因此我们错误地认为 SMTP Smuggling 这个研究结果不会有广泛影响。由于这个假设，我们于十一月底询问 CERT/CC 是否可以公开详细信息，并得到了可以进行公开的确认。

一场关于漏洞的演讲就规划到了第37届混沌沟通大会 (37C3)，十二月底举行。因此，漏洞需要在此之前公布。演讲是在 12 月 3 日被接受的，公告大约在两周后发布—就在假期前夕。上述引用中的“错误第认为”措辞似乎表明 SEC Consult 是承认这里犯了错误。此外，据称, 演讲中还包含了“一个体面的道歉”。

在（令人钦佩的详细）博客文章中提到的其他“供应商”之一是 Sendmail，但还有其他地方也提到了 Postfix。显然，SEC Consult 完全知道这两个邮件处理器是有漏洞的，但公司显然完全依赖 CERT/CC 通知到其他相关项目，这次显然并没有奏效。例如，Postfix 的创建者和维护者 Wietse Venema 就是称漏洞公告是“不负责任的披露过程” 的人员之一；他在 Postfix SMTP Smuggling页面中稍微缓和了一下这个立场，但仍指出“研究人员提供的关键信息在攻击发布之前未传递给 Postfix 维护者”。结果“可能是无意中会导致零日攻击”，他说。

漏洞

简单邮件传输协议 (SMTP, Simple Mail Transfer Protocol) 在RFC 5321中有描述，它提供了一个基于文本的协议，用于在网络上提交和交换电子邮件。从某种程度上说，这个漏洞是“鲁棒性原则”（也被称为“Postel's law”）在安全方面并不那么牢固的另一个迹象；在接受通过网络传输时采用了宽松的处理方式通常会导致问题。在这个例子中，与 SMTP 结束数据指示相关的行结束（line ending）的处理动作可能导致电子邮件被成功伪造出来，从而能通过各种认证检查。

SMTP DATA 命令会用在实际出现在电子邮件中的文本，其中包括 header 之类的；人们所说的“信封（envelope）” 描述了发送方和接收方，这是 DATA 命令之前的另一组 SMTP 命令（EHLO、MAIL FROM、RCPT TO）。宣布漏洞的博客文章中有很多图表和解释，适用于那些想要了解所有细节的人。DATA 命令以仅包含一个句点（"."）的空行结束；SMTP 的行结束定义为回车（CR 或“\r”）后跟换行（LF 或“\n”），因此数据的结束应该用“\r\n.\r\n”来表示。

事实证明，一些邮件处理工具只接受换行符作为行终止符，而其他邮件处理器则不是这样；对于“\n.\n”的解释就会出现不一样的行为，这可以用于在一封电子邮件消息中隐藏另一封电子邮件：

EHLO …
MAIL FROM: …
RCPT TO: …
DATA
From: …
To: …
Subject: …

innocuous email text
\n.\n
MAIL FROM: <admin@…>
RCPT TO: <victim@…>
DATA
From: Administrator <admin@…>
To: J. Random Victim <victim@…>
Subject: Beware of phishing scams

Like this one
\r\n.\r\n

如果接收它的 SMTP 服务器不将“\n.\n”视为 DATA 命令的终止，那么第二组命令就会出现在电子邮件文本中。然而，该电子邮件将被发送到另一台采用了不同的处理方式的 SMTP 服务器。如果目标 SMTP 服务器看到这个终止标志，它可能会把后续的内容作为全新的电子邮件来处理。这是类似于HTTP请求劫持的漏洞，其名称（smuggling）也来源于此。

还有一些行结束符变种（例如“\n.\r\n”），可以用来愚弄各种邮件处理服务。这个想法的核心是，出站邮件服务器会将“额外的内容”视为初始电子邮件消息的一部分并将邮件发送到另一台服务器，后者可能会将单个消息视为多个消息，并采取相应的操作。SPF检查可能会能判定为通过，甚至可以通过在伪装的头部中使用攻击者控制的 DKIM 密钥来伪造DKIM。DMARC可以用于阻止劫持，但它的常见配置仍然容易受到影响。此外，因为邮件服务（尤其是大型电子邮件提供商的服务）工具，通常会处理多个 domain，因此有机会在似乎无害的消息中伪造来自这个服务下面的其他 domain 的电子邮件。

博客文章主要集中在三个已经被确认的供应商上，但明确指出“Postfix 和 Sendmail 也[满足]要求，受影响且可能被劫持”。它提供了可以通过 GMX、Microsoft Exchange Online 或 Cisco Secure Email Cloud Gateway 伪造的多个 domain 的列表。实际上，SEC Consult 本身使用了 Cisco 的产品，因此公司已将其设置更改为非默认配置以避免该问题，Cisco 则未承认这是真正意义上的 bug。

Postfix 及其他

与此同时，在开源领域，人们似乎对这个漏洞毫无预警地出现感到相当惊讶。Marcus Meissner 在 oss-security 邮件列表上发布了有关漏洞的帖子：“看起来在圣诞节前我们没有足够好的流程来处理漏洞工作，现在又是一个例子”。他可能指的是SSH协议中的Terrapin漏洞，该漏洞于 12 月 18日公告，这是在在与许多种类的 SSH 实现项目协调之后。SMTP Smuggling 漏洞走了一条截然不同的道路，正如 Stuart Henderson 指出的：

“我对 SEC Consult 在这里的流程感到有点困惑。他们发现了一个影响各种软件的问题，包括一些广泛部署的开源软件，费了很多劲进行了协调的披露，但看他们的时间表，只与 gmx、microsoft 和 cisco 进行了联系？”

Meissner 指出，SUSE 并未被通过 VINCE 告知这个问题，而 Postfix 被告知的时间（根据 Venema 的帖子）也是在公告之后。Erik Auerswald 推测 SEC Consult 本以为 CERT/CC 会提醒其他受影响的项目，在它批准发布研究结果之前，实际上并不是这样。Rodrigo Freire 想知道为什么问题被视为漏洞，Auerswald 解释说：

任何使用受影响的出站服务器的用户都可以伪造来自同一出站服务器的其他任何用户的电子邮件，尽管有 SPF 和 DKIM（在某些情况下，DMARC+DKIM 也可以防止这种情况，不过也可以在特定情况下伪造更多发件人，详情请参见博客文章）。但要使其生效，入站服务器必须充当这一切混乱的助手。出站服务器和入站服务器都需要有不同的漏洞，才能实施攻击。这种特定的攻击可以在出站服务器或入站服务器中的任何一方来单方面阻止。

[…] 对于电子邮件服务器开源项目（也就是 oss-security 邮件列表）而言，主要的漏洞是它们作为了混乱的辅助者，入站服务器，因为这些电子邮件服务器的用户数通常比大型免费邮件提供商更少。但是，总的来说，它们也可能充当易受攻击的出站服务器，例如在[合法]用户帐户被攻破之后。

现在已经已经为 Sendmail、Postfix 和 Exim 分配了 CVE。Postfix 发布了带有新的 smtpd_forbid_bare_newline 选项（默认关闭，但将在即将发布的 Postfix 3.9 版本中默认为打开）的更新版本；那些不想升级的人可以使用现有选项解决大部分问题。Exim 为该问题提供了公告、错误报告和错误修复版本发布（4.97.1）。Sendmail 发布了一个快照版本（8.18.0.2），其中包含一个新选项来解决这个缺陷。然而，除了来自 SUSE 和 Slackware 的 Postfix 更新外，大多数发行版尚未为此问题发布更新，这让许多 Linux 用户面临风险。

因此，在假期期间，各个主要开源邮件项目纷纷努力修复这个漏洞，但显然这个过程失败了。我们还没有听到 CERT/CC 针对此事的观点，但无论是 CERT/CC 还是 SEC Consult，肯定都应该在发现问题后的数月内联系这些项目。尤其是考虑到 SEC Consult 已经了解到 Sendmail 和 Postfix 的影响，然而，很难理解为什么没有向这些项目的安全联系人发送一个简单的提醒邮件。

那些似乎有可能仍然受到这个缺陷影响的较小规模的邮件程序等工具，尽管它们可能一直没有知道这个事情，但是只要能提前一两个月给出预先通知，对于这些项目尤其是小型项目来说就会产生很大的差异。人们只能希望从中吸取教训，并期望今后的任何协调工作都能更好地进行协调（并充分沟通）。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～