哈佛架构计算机是否能够免受任意代码注入和执行攻击？
哈佛架构计算机具有独立的代码和数据存储器。 这是否使它们免受代码注入攻击（因为数据不能作为代码执行）？
Harvard architecture computers have separate code and data memories. Does this make them immune to code injection attacks (as data cannot be executed as code)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
它们比冯诺依曼架构更具免疫力，但并非完全如此。 每个架构都有一个转换点，数据开始被视为代码。 在冯·诺依曼中，它立即在 CPU 内部发生，而在哈佛中，它发生在为模块保留和声明内存之前（有时甚至在此之前，当构建系统准备文件时）。 这意味着在哈佛架构中，成功的代码注入攻击需要更加复杂和牵强，但不一定不可能。
如果有人可以将包含恶意代码的文件放入机器的存储（例如文件系统）中并导致缓冲区溢出，这将在返回到现有（有效、非恶意）代码时重定向，该代码将该恶意文件作为代码加载，并且如果该架构允许该文件开始执行（例如通过自初始化例程），这将是成功代码注入的示例。
They are somewhat more immune than Von Neumann architecture, but not entirely. Every architecture has a conversion point, where data starts being treated as code. In Von Neumann it happens immediately inside CPU, while in Harvard it happens before the memory is reserved and declared for the module (or sometimes even before that, when a file is being prepared by the build system). This means that in Harvard architecture a successful code injection attack needs to be a bit more complicated and far-fetching, but not necessarily impossible.
If one can place a file containing malicious code in the machine's storage (e.g. file system) and cause, say, a buffer overrun which would redirect on return to existing (valid, non-malicious) code which loads this malicious file as code and if the architecture allows this file to start executing (e.g. via self-initialization routine), that'll be an example of successful code injection.
这部分取决于您将什么视为“代码注入攻击”。
以 SQL 注入攻击为例。 SQL 查询本身永远不需要位于内存的可执行部分中，因为它被数据库引擎转换为本机代码（或解释的，或您希望使用的任何术语）。 然而，该 SQL 仍然可以被广泛地视为“代码”。
如果仅包括攻击者插入由处理器直接执行的本机代码（例如通过缓冲区溢出），并且如果阻止进程将数据复制到“代码区域”，那么它可以提供针对此类攻击的保护，是的。 （即使我想不出任何攻击媒介，我也不愿意声称 100% 的保护；这听起来万无一失，但安全性是一件棘手的事情。）
It partly depends on what you count as a "code injection attack".
Take a SQL injection attack, for example. The SQL query itself would never need to be in an executable part of memory, because it's converted into native code (or interpreted, or whatever terminology you wish to use) by the database engine. However, that SQL could still be broadly regarded as "code".
If you only include an attacker inserting native code to be executed directly by the processor (e.g. via a buffer overrun), and if the process is prevented from copying data into a "code area", then it provides protection against this sort of attack, yes. (I'm reluctant to claim 100% protection even if I can't think of any attack vectors; it sounds foolproof, but security's a tricky business.)
显然，有一些研究人员能够完成针对哈佛架构的永久代码注入攻击。 所以也许不像人们想象的那么安全。
Apparently, there are some researchers who were able to accomplish a permanent code injection attack on a Harvard architecture. So maybe not as secure as people thought.
大多数哈佛架构机器仍然使用公共共享内存空间来存储核心外部的数据和指令。 因此，仍然可以注入代码并将其作为指令执行。 事实上，当今大多数处理器内部都是哈佛架构，即使它们外部看起来是冯·诺依曼架构。
Most Harvard architecture machines still use a common shared memory space for both data and instructions outside of the core. So, it would still be possible to inject code and get it executed as instructions. In fact, most processors today are internally Harvard architecture, even if they look Von Neumann externally.
我的大学最近举行了一场硕士答辩，讨论的正是这个问题。 不幸的是，我没能参加。 我确信如果您联系瓦茨先生，他会愿意讨论这个问题。
http://www.cs.uidaho.edu/Defenses/KrisWatts.html
My university had a MS defense recently that discussed this very thing. Unfortunately, I wasn't able to attend. I'm sure if you contacted Mr. Watts he'd be willing to discuss it.
http://www.cs.uidaho.edu/Defenses/KrisWatts.html
x86 有一个分段架构可以做到这一点，并且它已被一些项目用来尝试阻止数据作为代码执行（由于 NX 位，这种努力现在大部分都被浪费了），并且它从未接近阻止数据流新的探索。 考虑一下仍然可以在野外利用的远程文件包含的数量惊人。
x86 has a segmentation architecture that does this, and it has been used by some projects to try to stop data from being executed as code (an effort which is now mostly wasted given the NX bit), and it never came close to stemming the flow of new exploits. Consider the amazing number of remote file inclusions still exploitable in the wild.