【发布时间】：2009-06-05 06:50:53
【问题描述】：
哈佛架构计算机具有独立的代码和数据存储器。这是否使它们免受代码注入攻击（因为数据不能作为代码执行）？
【问题讨论】：
标签： security cpu-architecture harvard-architecture
【发布时间】：2009-06-05 06:50:53
【问题描述】：
它们比冯诺依曼架构更具免疫力，但并非完全如此。每个架构都有一个转换点，数据开始被视为代码。在冯诺依曼，它立即发生在 CPU 内部，而在哈佛，它发生在为模块保留和声明内存之前（有时甚至在此之前，当构建系统准备文件时）。这意味着在哈佛架构中，成功的代码注入攻击需要更加复杂和牵强，但不一定是不可能的。
如果可以将包含恶意代码的文件放置在机器的存储（例如文件系统）中并导致缓冲区溢出，该缓冲区将在返回时重定向到现有的（有效的、非恶意的）代码，该代码将该恶意文件加载为代码，并且如果架构允许该文件开始执行（例如通过自初始化例程），这将是成功代码注入的示例。
【讨论】：
-
这里有一个想法可以帮助减轻转换点的不安全性：代码只能由验证代码签名的单独系统（最好是硬件）加载到代码内存中。那么潜在的不安全感就变成了：有哪些途径可用于修改检查代码签名的方式？例如，如果私钥被泄露，则代码签名验证系统将需要使用新密钥进行更新。这种更新机制将是一个潜在的安全漏洞。理想情况下，它将是外部和物理的东西（如智能卡）。
-
另外请注意，作为解释器或 JIT 编译器的代码仍然会在解释器/JIT VM 中受到代码注入攻击，即使在哈佛架构上也是如此。那么问题就变成了沙盒安全性。
这部分取决于您将什么视为“代码注入攻击”。
以 SQL 注入攻击为例。 SQL 查询本身永远不需要位于内存的可执行部分，因为它已被数据库引擎转换为本机代码（或解释，或您希望使用的任何术语）。但是，该 SQL 仍然可以被广泛地视为“代码”。
如果您只包括插入本机代码以由处理器直接执行的攻击者（例如，通过缓冲区溢出），并且如果阻止该进程将数据复制到“代码区域”，那么它可以提供针对此类的保护攻击，是的。 （即使我想不出任何攻击媒介，我也不愿意要求 100% 的保护；这听起来万无一失，但安全是一项棘手的工作。）
【讨论】：
显然，有some researchers 能够在哈佛架构上完成permanent code injection attack。所以可能不像人们想象的那么安全。
【讨论】：
-
这是要小心的地方，第一句话是“哈佛架构CPU设计在嵌入式世界中很常见”。如果你研究一下哈佛 Mark I 的实际设计，你很快就会意识到重要的不是 CPU 设计，而是指令和数据之间严格的物理分离——从它们各自的存储到执行，这并不重要。存在于我所知道的任何当前架构中。那篇论文涉及“修改后的哈佛架构”。
-
@avgvstvs：一些 DSP 或微控制器确实是哈佛的，具有用于指令存储器和数据的单独总线。这个想法是他们从 ROM 运行代码，并有一些暂存 RAM。甚至ARM9 apparently had separate external busses（可以以创建修改后的哈佛而不是哈佛的方式连接）。如果在数据和指令内存之间移动需要写入磁盘并重新读取另一个内存，我想大多数人会称之为哈佛，而不是修改后的哈佛。 （虽然修改后的哈佛不仅仅包括拆分 L1）
-
再次，我回到 Mark I 不是简单地在公共汽车上分离的事实，它完全分离回单独的数据和指令存储。也许大多数人会认为共享 ROM 仍然是“哈佛”，但我不这么认为。有问题的攻击能够成功的原因是因为 ROM 是共享的。
大多数哈佛架构机器仍然使用公共共享内存空间来存储内核之外的数据和指令。因此，仍然可以注入代码并将其作为指令执行。事实上，今天的大多数处理器在内部都是哈佛架构，即使它们在外部看起来是冯诺依曼。
【讨论】：
-
现代主流机器（如 x86、ARM/AArch64 等）是“修改后的哈佛”（例如 split L1d and L1i caches），以加速你所说的表现得像冯诺依曼的 CPU。 en.wikipedia.org/wiki/Modified_Harvard_architecture。说“大多数处理器都是哈佛”是一个延伸，除非您包含具有单独 ROM 和 RAM 的微控制器，这些微控制器实际上是真正的哈佛，需要单独的指令来读取程序存储器。 x86 甚至具有连贯的 I-cache，因此哈佛性是完全不可见的。 （但大多数像 AArch64 这样的 RISCS 都没有。）
我的大学最近有一个 MS 辩护，讨论了这个问题。不幸的是，我无法参加。我敢肯定，如果你联系 Watts 先生，他会愿意讨论的。
【讨论】：
x86 有一个分段架构可以做到这一点，并且它已被一些项目用于尝试阻止数据作为代码执行（考虑到 NX 位，这项工作现在大部分都被浪费了），而且它从未接近过阻止新漏洞的流动。考虑一下仍然可以在野外利用的惊人数量的远程文件包含。
【讨论】：
-
这是一个很好的答案，但对这个问题并不真正
-
Hardware NX（具有完整的 W^X 映射选项）确实阻止了 代码注入 攻击。这就是为什么针对现代软件的攻击通常必须是 ROP 攻击，它接管控制流以获取代码序列（小工具）已经在二进制文件中以特定顺序执行。即使是只能从真正的只读 ROM 执行代码的纯哈佛机器也可能容易受到攻击。但这不会是代码注入攻击。