2026年5月的Fediverse软件漏洞

# 2026年5月联邦宇宙软件漏洞 来源：https://w.on-t.work/activitypub/may-2026-vulnerability 2026\-05备选标题：*你认识的最烦人的人，刚刚有了变得更烦人的理由* (viamia (https://void.rehab/notes/a1zk9j8juwp2bzcw))在这篇文章发布之前不久，Mastodon、Iceshrimp.net、Misskey（及其众多分支）、Wafrn 以及其他任何实现 LD-Signatures 的联邦宇宙软件，应该都已经发布了安全更新。**请立即应用它。** 在 Mastodon 联系并告知我们可能受到影响后，我参与了 Iceshrimp.net 方面对此漏洞的应对工作。这篇杂乱无章的文字是我个人的一些想法——鉴于我对被利用的代码一直持有尖锐的看法，我觉得说一句“我早就告诉过你们”是合适的。 ## 问题出在哪里 你不需要是 Claude Mythos 也能想到，这可能是一个值得寻找漏洞的好地方。 ## 房间里的大象 但即便事后看起来很明显，并不意味着很多人真的会去那里寻找。这个特定的漏洞，据联系我们的 Mastodon 维护者称，是由 Anthropic 发现的（考虑到时间点，我猜是通过 Mythos 发现的）。 > Doyensec 代表 Anthropic 联系我们，报告了 Mastodon 在验证关联数据签名（Linked Data Signatures）方面的一个漏洞。在评估时，我们还发现了该漏洞的其他变种。 由于与 Anthropic 有关联，我们最初对将其视为安全漏洞有些犹豫，我能感觉到我的同事们在修补时也有些不安。 在等待报告者提供概念验证以确认这是安全问题的短暂时间里，我本人就找到了另一种在 Iceshrimp.net 上利用该漏洞的方法。这并不适用于 Mastodon，因为 Iceshrimp.net 会做 JSON-LD 展开（仅做最低限度的展开，因此才有了这个 bug），而 Mastodon 不会。 ## 那么，*实际*上到底出了什么问题 有多种方式可以将同一个 RDF 图（LD-Signatures 验证的对象）表示为紧凑的 JSON-LD（几乎所有实现都解析这种格式，但极少做展开）。 因此，如果你说服受害者内嵌一个恶意的 JSON-LD 对象，然后签署“包装”对象（例如，通过转发一条恶意的帖子），就可以利用某些晦涩的 JSON-LD 功能重新排列属性顺序，从而让攻击者影响由受害者签名签署的对象。 这一切的根本原因是，LD-Signatures 以及“按规范”的 ActivityStreams，都是基于 RDF 三元组和图工作的，而现实世界中几乎所有实现都将 ActivityStreams 视为带有一些烦人怪癖的普通 JSON。有趣的是，规范指出这样做是可以的（https://www.w3.org/TR/activitystreams-core/#:~:text=but%20does%20not%20require%20JSON%2DLD%20processing）。 ## 现在进入“我早就告诉过你们”部分 这基本上每个人都在做，因为在当代 ActivityPub 中，你没有足够的反向链接和其他线索来验证某人是否有权做某事。 ## 缓解措施 而且这种暴力缓解措施实际上会破坏多少现实中的通信？嗯，我没有确切数字，但我确实 grep 了 https://observatory.cyber.harvard.edu/snapshots 中上述三个属性，得到了*零*个结果。 希望这是逐步废除 JSON-LD 的一步，这样我们就可以砍掉一大块复杂性——那些没有喝过 W3C 迷魂汤的人根本不在乎的复杂性——并为剩下那些仍然亲手敲键盘（而不是告诉 Grok 他们的祖母在一家从不犯错的工厂工作，它应该纪念祖母而绝不犯错）的人，带来一个更好的未来：拥有可用的模式验证、代码生成，以及更少的“自毁机关”。 ## 为什么 JSON-LD 展开没能阻止这个问题？ 这样做难道不对吗？Iceshrimp.net 浪费那么多 CPU 周期是徒劳的吗？（https://wetdry.world/@kopper/114678917311316875） 嗯，要正确处理这个问题，仅仅展开是不够的。你确实需要将 JSON-LD 视为图来处理。 JSON-LD 展开所做的全部工作，就是将 `@context` 中的值“内联”进来。它有助于 - 减少歧义 - 标准化命名空间 展开后得到的结构大致与输入的紧凑数据相同，只是所有属性名称都变成了带命名空间的完整 IRI，诸如列表与集合的区别变得明确，本地化值带有明确的语言标记，并且诸如上述的 JSON-LD 处理操作会被应用。 对于我们与 Mastodon 共享的漏洞，展开并没有起作用，因为我们仍然依赖 JSON 中属性的位置来确定对象，而不是依赖三元组。要做到后者，我相信你会使用扁平化（flattening），这样速度更慢（https://it.w.on-t.work/ldnet2025.html）。原因之一是所有 JSON-LD 算法都依赖展开。即使你重新压缩一个已压缩的值，它内部也会在过程中被展开。 多个值的问题是导致 Iceshrimp.net 特定漏洞的原因，因为展开后我们总是 Just™ 取返回数组的第一个元素。在紧凑表示中使用 `@graph` 属性，可以让你以任意顺序在根层级放置多个对象。而且由于 RDF 对这个集合的顺序不敏感，LD-Signature 无论如何都会通过验证。 ## ……所以不要走捷径？ 我认为，所有这些现实情况都鼓励走捷径，而不是做正确的事情。 在这种情况下，“正确的事情”被非常慢的库（或者如果你用的是稍微冷门的语言，连库都没有）所禁锢。这些库依赖古老的外部包，它们不断为相同的数据分配新的列表，而不是重用已有的列表；它们甚至还没有更新到异步 I/O——尽管是用第二个引入 `async` 关键字的语言编写的（我猜？仅次于 F#）——甚至在内部也是如此。 即使存在完美的库，算法本身也在性能上留下了很多空间。如果你按照 W3C 算法实现 JSON-LD，你必须有不断修改的 JSON DOM。这对你的内存和 CPU 缓存来说肯定很有趣。哦对了，所有操作都必须是异步的，因为任何方法都可能调用上下文处理，从而发起网络请求。当你解析过程还有网络依赖时，你喜欢吗？ 最后，为了加入今天的热点内容：这意味着至少多了一个可能受到供应链攻击的代码依赖。 我反复看到的唯一论点是，将诸如 Wikidata 以及（我不知道）全球航运等事物，连接到你用来发帖的同一数据格式中。“你难道不希望你的帖子包含关于你刚玩过的游戏的 Wikidata 信息吗？[如何？][为什么？][难道你不能为此写一个 FEP 而无需 RDF 吗？]” 所有这些“一种技术代表一切”的提议，在我身上唤起的感受是： - 恐惧 - 厌恶 - 以及一种深深的无用感 ## 所有这些的代价 所有这些复杂性也是有代价的，尽管在所有人[需要引用]开始将语言模型投向任何看起来像互联网的东西、以期快速获得漏洞赏金/廉价营销/可出售的漏洞之前，其作为“攻击面”的可行性可以合理地轻描淡写为“有用”。 据我所知，最近许多由语言模型辅助发现的漏洞，都是针对“如果我们还能做 X 岂不是很酷”这类功能。并非严格必要，但可能在某些时候对大约两个人有用， - 但代价是让整个生态系统变得脆弱。 我希望，如果这场混乱能有什么结果的话，那就是“全行业”的反应：让我们坐下来，重新评估我们系统中某些组成部分的必要性。 或者至少，如果我们能以更精简的实现、减少出错的可能性，或者提供某种方式只让那些使用这些功能的人承担风险，同时提供相同的效用。 我不知道。我不是专业人士。至今没有人付给我超过总共 10 美元让我写代码。 ### 所有这些的代价：补充说明 > *注：本节的其余部分有点偏离文章主题，但我需要一个地方把这些话说出来*。也许你能看出我是在几天前的凌晨 2 点左右写完这一切的，那时我本该在睡觉。 所有这些不必要的复杂性的代价是，两个使用不同软件但具有相同模态（例如微博客）的用户无法通信，因为其中一人期望 `as:to` 值被包裹在数组中，尽管 JSON-LD 压缩会为任何只有一个元素的集合移除包裹数组。 所有这些的代价是，整个生态系统在原地打转，试图修补他们自己破坏的东西，而没有这种包袱的生态系统可以继续前进，做那些对用户可见、甚至偶尔有益的事情。 所有这些的代价是一种虚假的可扩展性，伴随着那些“架构宇航员”（https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/）的宏大梦想——他们没有写过一行代码——但通过实际用户的诉求，却转化为对维护者的要求：让一切与一切兼容，不管是否合理。 是的。让专门用于发布图片和视频的平台也支持阅读微博。让那个带有卡片式 UI 的推特克隆——即使其 500 字符限制下也难以使用——实现长文本、内嵌图片和表格，并支持 Hubzilla 那种因为某种该死的原因 `@` 符号放在提及之外的提及语法。 为 Threads 铺路，让它们在你的博客文章中内联显示，以便放置广告和跟踪，并以互操作性为借口。把代码问题追踪器变成微博线程，这样你甚至不需要点击链接就能去骚扰。 所有这些的代价是一堆被遗弃的软件，以及每隔几年就得进行的账户迁移和服务器关闭来跳船。 所有这些的代价是一群精疲力尽且无偿的维护者，他们通常是边缘化群体（https://privacy.thenexus.today/mastodon-a-partial-history/#2017），勉强维持生计，同时——至少在我个人情况下——不健康地逼迫自己，因为毕竟，这是唯一能让他们与朋友和同行开玩笑、保持某种势头、并与他们兴趣相投的剩余选择了。 所有这些的代价是一群失望的用户，他们认为去中心化就意味着一切都很粗糙。他们认为一旦将两台服务器连接起来，所有精致感就会立刻消失，因为他们有更好的事情要做（比如过自己的生活），而不是意识到这一切都是可以修复的，并不是我们要求他们接受的固有权衡。 当他们理所当然地拒绝这种权衡，并开始在其他（有时是半（https://dustycloud.org/blog/re-re-bluesky-decentralization/）集中化的、目前但不一定（https://w.on-t.work/notes?cursor=20260417-150489-#20260417-150489）是集中化的）替代品上真正享受乐趣时，那些最大声的嘴巴——他们极力将自己定位为整个网络的代言人，包括但不限于将所使用的软件名称放在他们的显示名中——所表现出的居高临下态度，意味着我们可能永远失去了这些人的信任，无论他们当前的主机对他们做了什么。 好吧，我觉得最后一部分有点过头了。不过，你明白了吧？对吧？这真的可持续吗？我们作为生态系统，是否应该继续为大约 10 个已经既有钱又有影响力、可以飞到异国参加会议（且不发布视频录像）的家伙的娱乐，而把这些坑挖得更深？