马脚与打击无处不在。最近，剑桥大学的两位研讨职员发现了一个可以影响计算机代码编译器和软件开发环境的马脚——Trojan Source（木马源） 。该马脚几乎影响所有计算机语言，包括对 C、C++、C#、JavaScript、Java、Rust、Go 和 Python 。
此外，恶意代码可以将 Trojan Source 用于供应链打击。
论文地址：https://trojansource.codes/trojan-source.pdf
GitHub 地址：https://github.com/nickboucher/trojan-source
Trojan Source 打击方法利用的是字符编码标准 Unicode ，有以下两种打击方法：
第一种是通过 Unicode 的 Bidi 算法（CVE-2021-42574），该算法处理从左到右（如英语）和从右到左（如阿拉伯语和希伯来语）剧本卖弄递次。该马脚准许对字符进行视觉上的重新排序，使其呈现与编译器和解释器所不同的逻辑递次；
第二种是同源打击 (CVE-2021-42694)，两个不同的字符具有相似的视觉体现，例如拉丁语 H 和西里尔字母Н。
研讨职员体现如果打击者通过逃过人类审阅成功地将目标马脚提交到开源代码中，下游软件可能会继承该马脚。在 GitHub 上的存储库中，他们提供了概念验证 (PoC) 剧本。
Trojan-Source 打击
字符重新排序方法
Unicode 标准规定，内存体现递次称为逻辑递次，当文本在一行的时候，大多数剧本从左往右卖弄字符（例如英语）。然而，也有一些剧本（如阿拉伯语或希伯来语）卖弄文本的自然递次是从右往左。当混合具有不同卖弄递次的剧本时，必须有一种确定性的方法来解决方向冲突。对于 Unicode 来说，双向或 Bidi 算法可以实现。
某些场景下，Bidi 算法设置的默认排序可能不够。对于这些情况，Bidi 算法提供遮盖控制字符（override control characters）。Bidi 算法遮盖是不可见的字符，从而可以切换字符组的卖弄递次。
例如，考虑以下 Unicode 字符序列：RLI a b c PDI，那么将卖弄为：c b a。
下表 I 提供了与此打击相关的控制符列表：
隔离重新排序方法
在 Bidi 规范中，隔离（isolates）是被视为单个实体的字符组；也就是说，当卖弄递次被重写时，整个一组字符将作为单个块移动，隔离可以嵌套。
假设 Unicode 字符为：RLI LRI 4 5 6 PDI LRI 1 2 3 PDI PDI，那么将卖弄为：1 2 3 4 5 6。
相互嵌入多层 LRI 和 RLI，可以近乎恣意地重新排序字符串。那么打击者就可以将杂乱的字符，经过这种方法，将自己想要的功能插入到当前的开源项目中，让用户下载后执行，从而在不知情的情况下来执行马脚代码。
语法依从性
大多数设计良好的编程语言不准许在源代码中使用恣意控制字符，因为它们被视为影响逻辑的 token。因此，在源代码中随机放置 Bidi 遮盖字符通常会导致编译器或解释器语法错误。为了避免这种错误，我们可以利用编程语言的以下两个原则：
诠释：大多数编程语言都准许编译器和解释器忽略所有文本（包括控制符）诠释；
字符串：许多编程语言准许字符串可以包含恣意字符，同理也包括控制符。
虽然诠释和字符串都具有指示其开始和结束的特定于语法的语义，但 Bidi 遮盖不遵守这些界限。因此，通过将 Bidi 遮盖字符专门放置在诠释和字符串中，我们能够以大多数编译器可接受的方法将它们注入到源代码中。
示例展示
如下图所示，通过恣意控制符改变了代码逻辑。下列代码中的 if 条件没有执行，而是被放置在诠释部分，程序卖弄效果起到了欺骗用户的作用。
研讨职员还展示了如何在 C++ 中执行同源文字打击。他们使用了两个看起来相似但实际上不同的 H，蓝色的拉丁语 H 和红色的西里尔字母Н。当进行编译时，该程序输出文本「Goodbye, World!」。
加强防御
这样的打击可能很难检测，因为经过渲染的源代码看起来非常完美。如果逻辑上的变化足够微小，以至于后续测试中未被发现，那么打击者可能会在不被发现的情况下引入有针对性的马脚。
同样令人担忧的是，Bidi 遮盖字符通过复制、粘贴操作，仍然存在于浏览器、编辑器和操作系统上。
「开发者将代码从不受信任的来源复制到受保护的代码库中，这种做法可能无意中引入了一个不可见马脚，」剑桥大学计算机安全教授、该研讨的合著者 Anderson 体现。「这种代码复制是现实世界安全马脚的重要来源。」
约翰霍普金斯信息安全研讨所的副教授 Matthew Green 体现，「剑桥研讨清楚地表明，大多数编译器都可以被 Unicode 欺骗，以不同于研讨者预期的方法处理代码。」
好消息是，研讨职员进行了广泛的马脚扫描，还没有人利用这一马脚。坏消息是目前还没有防御措施，将来可能会有人利用该马脚进行一些破坏。
Green 体现：希望编译器和代码编辑器开发职员能够快速修补这个马脚！但由于有些人不定期更新他们的开发工具，至少在一段时间内会有一些风险。
图源：XKCD.com/2347/
加州大学伯克利分校计算机科学系的讲师 Nicholas Weaver 体现，剑桥提出了一组非常简单、优雅的打击，可能会使供应链打击变得更加严重。
人类已经很难从源代码中区分「this is OK、this is evil」，Weaver 体现。对于这种打击，你可以使用改变方向来改变诠释和字符串的呈现方法，例如「This is okay」只是一种呈现形式，但「This is」okay 才是它在代码中的存在方法。幸运的是，它有一个非常容易扫描的标记，因此编译器在将来遇到它时可以「检测」它。
研讨职员体现，软件公司在最初表露期间，提供了 99 天的禁锢期，以准许通过软件更新修复受影响的产品。
研讨职员写道：「我们收到了各种各样的回应，包括修补承诺、Bug 赏金计划、快速驳回等。在我们与之合作的 19 家软件供应商中，有 7 家使用外包平台接收马脚表露，6 家拥有专门的马脚表露门户网站，4 家通过 PGP 加密电子邮件接受表露，另外两家仅通过非 PGP 电子邮件接受表露。他们都确认收到了我们的表露，最终 9 家承诺发布补丁。」
此外，还有 11 家接受者有 Bug 赏金计划，为马脚表露提供报酬。但研讨职员报告说，只有 5 家支付赏金，平均支付 2,246 美元。
Anderson 体现，「到目前为止大约有一半的组织已经承诺提供补丁，而其他组织还在拖延。我们将接下来将监控他们的部署，还希望 GitHub、Gitlab 、 Atlassian 采取行动。」
参考链接：
https://krebsonsecurity.com/2021/11/trojan-source-bug-threatens-the-security-of-all-code/
http://cn-sec.com/archives/609155.html
http://cn-sec.com/archives/609155.html