Ken Thompson的编译器黑客仍然是威胁吗？

#1 楼

必须从上下文中了解这种技巧。它发布的时间和文化是，在各种不同硬件上运行的Unix是主要系统。

使攻击如此可怕的是C编译器是这些系统。首次安装时，系统中的几乎所有内容都通过了编译器（由于硬件异构，因此二进制发行版很少见）。每个人都一直在编译东西。人们会定期检查源代码（他们通常不得不进行调整以使其完全得以编译），因此让编译器注入后门似乎是一种无法捉住您的“完美犯罪”情况。 br />如今，硬件更加兼容，因此编译器在系统的日常操作中所扮演的角色要小得多。受损的编译器不再是最可怕的情况-rootkit和受损的BIOS甚至更难检测和消除。

#2 楼

演讲的目的不是要强调需要解决的漏洞，也不是提出我们需要意识到的理论漏洞。安全，我们不想不必信任任何人，但不幸的是这是不可能的。您始终必须信任某人（因此，标题为：“ Reflection on On Trusting Trust”）


即使您是偏执狂型用户，也对其桌面硬盘驱动器进行加密并且拒绝运行任何驱动程序您自己编译的软件，您仍然需要信任您的操作系统。即使您自己编译操作系统，也仍然需要信任您使用的编译器。即使您编译自己的编译器，您仍然需要信任该编译器！而且甚至都没有提到硬件制造商！

您根本无法摆脱不信任任何人的情况。这就是他试图克服的重点。

#3 楼

否

最初描述的攻击绝不是威胁。尽管理论上编译器可以做到这一点，但要真正抵御攻击，就需要对编译器进行编程，以使其识别出所编译的源代码何时属于编译器，并找出原因如何修改任意源代码以将hack插入到其中。 />例如，假设链接格式将数据长度或已编译机器代码的偏移量存储在可执行文件中的某个位置。编译器必须自己确定其中哪些需要更新，以及在插入漏洞有效负载时需要在何处更新。编译器的后续版本（无害版本）可以任意更改此格式，因此漏洞利用代码将需要有效地理解这些概念。最后我检查了一下，目前的技术水平是生成实际上由其类型决定的代码。看：几乎没有人能做到这一点；您必须先学习编程语言并首先了解代码库。

即使解决了AI问题，人们也会注意到，如果将微型编译器编译为二进制文件，并且链接了庞大的AI库，

类似的攻击：自举信任

但是，对攻击进行概括是很重要的。基本问题是您的信任链必须从某处开始，并且在许多领域，其起源都可能以一种难以察觉的方式破坏整个链。在现实生活中

您的操作系统（例如Ubuntu Linux）通过对照存储库的签名密钥（使用公共密钥加密）检查下载的更新包来确保更新的安全性（完整性）。但是，只有在您可以证明签名密钥由合法来源拥有的情况下，才能保证更新的真实性。

您从哪里获得签名密钥？首次下载操作系统发行版时。

您必须相信信任链的来源（此签名密钥）不是邪恶的。

MITM您与Ubuntu下载服务器之间的Internet连接（可能是您的ISP，控制Internet访问的政府（例如中国）或Ubuntu的托管提供商）可能会劫持此过程：


检测到您正在下载Ubuntu CD映像。这很简单：请参见将请求发送到任何（公开列出的）Ubuntu镜像，并询问ISO映像的文件名。
从自己的服务器提供请求，为您提供一个包含攻击者的公钥和存储库位置（而不是Ubuntu的）。

此后，您将从攻击者的服务器安全地获取更新。更新以root用户身份运行，因此攻击者拥有完全控制权。但这要求您使用哈希来验证下载的CD映像（很少有人这样做），并且哈希本身必须安全地下载，例如，通过HTTPS。而且如果攻击者可以在计算机上添加证书（在公司环境中常见）或控制证书颁发机构（例如中国），那么即使HTTPS也无法提供保护。

#4 楼

首先，我最喜欢的这种骇客文章叫做Strange Loops。

今天，肯定可以在任何主要的开源OS项目中（特别是Linux，* BSD和喜欢。我希望它几乎可以相同地工作。例如，您下载了一个FreeBSD副本，该副本具有被利用的编译器来修改openssh。从那时起，每次升级openssh或按源升级编译器时，都会继续出现此问题。假设攻击者首先利用了用于打包FreeBSD的系统（可能是因为映像本身已损坏，或者攻击者实际上是打包者），那么每次系统重建FreeBSD二进制文件时，它都会重新注入问题。攻击失败的方法有很多，但与Ken的攻击失败的方式（**）根本没有区别。世界真的并没有发生太大变化。

当然，类似的攻击可能被其所有者轻松（或更容易）注入到Java，iOS SDK，Windows或任何其他系统中其他系统。甚至可以将某些类型的安全漏洞设计到硬件中（特别是削弱随机数生成）。您是否应该期望在任何特定系统中都存在这种漏洞？不。出于各种实际原因，我认为这种可能性很小。随着时间的流逝，随着代码的更改和更改，这种黑客入侵会导致奇怪错误的可能性增加。这就增加了被发现的可能性。精巧的后门将需要阴谋来维持。当然，我们知道，在各种电信和网络系统中都已安装了“合法拦截”后门，因此在许多情况下，这种精心设计的技巧是不必要的。 hack是公开安装的。

因此，总是要深入防御。

（**）假设Ken的袭击确实存在。他只是讨论了如何实现。据我所知，他没有说他实际上做了。

#5 楼

这会影响所有语言吗？
此攻击主要影响自托管的语言。那是编译器是用语言本身编写的语言。 C，Squeak Smalltalk和PyPy Python解释器将受到此影响。 Perl，JavaScript和CPython Python解释器不会。
这与即时编译有什么关系？
不是很多。正是编译器的自托管特性允许隐藏黑客。我不知道任何自托管的JIT编译器。 （也许是LLVM吗？）
是否有诸如在* nix系统上运行登录时处理登录的程序之类的功能？
不是通常如此。但是问题不是何时编译，而是由哪个编译器进行编译。如果登录程序是由受污染的编译器编译的，它将被污染。如果它是由干净的编译器编译的，那么它会是干净的。这仍然是理论上的威胁，但可能性很小。
您可以采取的缓解措施之一就是使用多个编译器。例如，本身由GCC编译的LLVM编译器不会通过后门。同样，LLVM编译的GCC不会通过后门。因此，如果您担心这种攻击，则可以使用另一种编译器来编译您的编译器。这意味着邪恶的黑客（在您的OS供应商处？）将不得不污染两个编译器才能相互识别。一个更困难的问题。

#6 楼

理论上有可能发生这种情况。但是，有一种方法可以通过David A. Wheeler的Diverse双重编译来检查特定的编译器（带有可用的源代码）是否已被破坏。

基本上，请同时使用可疑的编译器和其他编译器。独立开发的编译器可以编译可疑编译器的源代码。这将为您提供SCsc和SCT。现在，使用这两个二进制文件编译可疑源。如果生成的二进制文件是相同的（除了可能合理地变化的各种事物，例如各种时间戳），则可疑编译器实际上并未滥用信任。

#7 楼

作为一种特定的攻击，它与以往一样具有威胁，几乎完全没有威胁。


这与即时编译有什么关系？ br />

不确定您的意思。准星对此有免疫力吗？不。它更容易受到伤害吗？并不是的。作为开发人员，您的应用程序更容易受到攻击，因为您无法验证未完成该应用程序。请注意，您尚未开发的应用程序基本上不受此限制和所有实际变化的影响，您只需要担心比您的代码更新的编译器。


功能类似于程序处理登录运行时已编译的* nix系统吗？


这真的不相关。


这仍然是有效的威胁，还是有自1984年以来，编译安全性的发展阻止了它成为一个重大问题？


没有真正的编译安全性，而且不可能。那确实是他讲话的重点，在某个点上您必须信任某人。


这会影响所有语言吗？


是的。从根本上说，有时必须将您的指令转换为计算机可执行的指令，并且翻译可能会错误地进行。

#8 楼

就我们所知道的..这时正在发生：

很难确定...

#9 楼

大卫·惠勒（David Wheeler）的文章不错：http://www.dwheeler.com/trusting-trust/

我，我更担心硬件攻击。我认为我们需要一个完整的带有FLOSS源代码的VLSI设计工具链，我们可以对其进行修改和编译，从而使我们能够构建一个没有工具插入后门的微处理器。这些工具还应该让我们了解芯片上任何晶体管的用途。然后，我们可以打开成品芯片的样本，并用显微镜对其进行检查，确保它们具有与工具所称的电路相同的电路。

#10 楼

最终用户可以访问源代码的系统就是您必须隐藏这种类型的攻击的系统。这些将是当今世界上的开源系统。问题是，尽管所有Linux系统都依赖于一个编译器，但是对于所有主要Linux发行版，攻击都必须进入构建服务器。由于这些攻击者不会直接为每个编译器版本下载编译器二进制文件，因此攻击的源将必须存在于至少一个先前版本的编译器中的其生成服务器上。他们必须以二进制文件的形式下载该编译器的第一个版本。

#11 楼

如果一个人拥有用于编译器/构建系统的源代码，其输出不应该依赖于所提供源文件的内容以外的内容，并且如果一个人具有其他几个编译器并且知道它们都不都包含相同的编译器hack，则可以确保其中一个可执行文件不依赖于源代码。

假定其中一个具有编译器/链接器包（例如Groucho Suite）的源代码，其编写方式应使其输出将不依赖于任何未指定的行为，也不依赖于输入源文件的内容以外的任何东西，并且依赖于在各种独立生产的编译器/链接器程序包（例如Harpo Suite，Chico Suite和Zeppo Suite），为每个生成不同的可执行文件集（称为G-Harpo，G-Chico和G-Zeppo）。这些可执行文件包含不同的指令序列并不奇怪，但是它们在功能上应该相同。但是，证明它们在所有情况下在功能上都是相同的，这可能是一个棘手的问题。

幸运的是，如果仅将生成的可执行文件用于一个目的，则不需要这种证明：格劳乔套房再次出现。如果一个人使用G-Harpo（生成GG-Harpo），G-Chico（GG-Chico）和G-Zeppo（GG-Zeppo）来编译Groucho套件，则生成的所有三个文件GG-Harpo，GG-Chico和GG-Zeppo，都应逐字节相同。如果文件匹配，则意味着它们中存在的任何“编译器病毒”必须在所有文件中均存在（由于所有三个文件都是逐字节相同的，因此它们的行为在任何情况下都不可能有所不同）方式）。

根据其他编译器的年龄和血统，有可能确保这种病毒不会合理地存在于它们中。例如，如果使用一台古老的Macintosh来提供一台编译器，该编译器是通过1980年代编写的MPW版本从2007年从头编写的，则1980年代的编译器将不知道在2007编译器中插入病毒的位置。今天的编译器可能有可能进行足够多的代码分析以找出答案，但是这种分析所需的计算水平将远远超过简单地编译代码所需的计算水平，并且不会很好地被忽视在一个以编译速度为主要卖点的市场中。

我认为，如果人们正在使用编译工具，则要生成的可执行文件中的字节不应以任何方式依赖于其他任何东西。与提交的源文件的内容相比，可以实现对Thompson风格病毒的合理良好的免疫力。不幸的是，由于某些原因，在某些环境中，编译中的不确定性似乎被认为是正常的。我认识到，在多CPU系统上，如果允许代码生成的某些方面根据两个线程中的哪个先完成工作而有所不同，则编译器可能会运行得更快。

另一方面，我不确定我是否有任何理由认为编译器/链接器不应提供“规范输出”模式，其中输出仅取决于源文件和“编译日期”，而该日期可能会被覆盖用户。即使以这种方式编译代码所花的时间是普通编译时间的两倍，我还是建议完全从源材料中逐字节地重新创建任何“发布版本”，这将具有相当大的价值，即使这意味着发布版本比“正常版本”需要更长的时间。