11 Stimmen

Sind Computer mit Harvard-Architektur immun gegen Angriffe zur Einspeisung und Ausführung von beliebigem Code?

Computer mit Harvard-Architektur haben getrennte Code- und Datenspeicher. Macht sie das immun gegen Code-Injection-Angriffe (da Daten nicht als Code ausgeführt werden können)?

16voto

Rom Punkte 4053

Sie sind etwas immuner als die Von-Neumann-Architektur, aber nicht ganz. Jede Architektur hat einen Konvertierungspunkt, an dem die Daten als Code behandelt werden. Bei der Von-Neumann-Architektur geschieht dies unmittelbar in der CPU, während es bei der Harvard-Architektur geschieht, bevor der Speicher für das Modul reserviert und deklariert wird (oder manchmal sogar schon vorher, wenn eine Datei vom Build-System vorbereitet wird). Das bedeutet, dass in der Harvard-Architektur ein erfolgreicher Code-Injektionsangriff etwas komplizierter und weitreichender sein muss, aber nicht unbedingt unmöglich.

Wenn es gelingt, eine Datei mit bösartigem Code im Speicher des Rechners (z. B. im Dateisystem) zu platzieren und z. B. einen Pufferüberlauf zu verursachen, der bei der Rückkehr zu vorhandenem (gültigem, nicht bösartigem) Code umleitet, der diese bösartige Datei als Code lädt, und wenn die Architektur es zulässt, dass diese Datei mit der Ausführung beginnt (z. B. über eine Selbstinitialisierungsroutine), wäre dies ein Beispiel für eine erfolgreiche Code-Injektion.

0 Stimmen

Hier ist ein Gedanke, der dazu beitragen könnte, die Unsicherheit am Konvertierungspunkt zu verringern: Code kann nur durch ein separates System (vorzugsweise Hardware), das die Codesignaturen validiert, in den Codespeicher geladen werden. Die potenzielle Unsicherheit ist dann: Welche Möglichkeiten gibt es, die Art und Weise der Überprüfung von Codesignaturen zu ändern? Wenn beispielsweise private Schlüssel kompromittiert würden, müsste das System zur Validierung von Codesignaturen mit neuen Schlüsseln aktualisiert werden. Dieser Aktualisierungsmechanismus wäre eine potenzielle Sicherheitslücke. Idealerweise wäre es etwas Externes und Physisches (wie eine Chipkarte).

0 Stimmen

Außerdem ist zu beachten, dass Code, der als Interpreter oder JIT-Compiler fungiert, selbst auf einer Harvard-Architektur immer noch Gegenstand von Code-Injection-Angriffen innerhalb des Interpreters/der JIT-VM sein kann. Dann wird das Problem eher zur Sandbox-Sicherheit.

7voto

Jon Skeet Punkte 1325502

Das hängt zum Teil davon ab, was Sie unter einem "Code-Injektionsangriff" verstehen.

Nehmen Sie zum Beispiel einen SQL-Injection-Angriff. Die SQL-Abfrage selbst müsste sich nie in einem ausführbaren Teil des Speichers befinden, da sie von der Datenbank-Engine in nativen Code umgewandelt (oder interpretiert, oder wie auch immer man sich ausdrücken möchte) wird. Dennoch könnte diese SQL-Abfrage im Großen und Ganzen als "Code" betrachtet werden.

Wenn Sie nur einen Angreifer einbeziehen, der nativen Code einfügt, der direkt vom Prozessor ausgeführt wird (z. B. über einen Pufferüberlauf), und wenn der Prozess daran gehindert wird, Daten in einen "Codebereich" zu kopieren, dann bietet es Schutz gegen diese Art von Angriff, ja. (Ich zögere, einen 100%igen Schutz zu behaupten, selbst wenn mir keine Angriffsvektoren einfallen; es klingt narrensicher, aber Sicherheit ist ein heikles Geschäft).

5voto

Kekoa Punkte 26946

Offensichtlich gibt es einige Forscher die in der Lage waren, eine permanenter Code-Injektionsangriff auf einer Harvard-Architektur. Also vielleicht doch nicht so sicher, wie man dachte.

1 Stimmen

An dieser Stelle lohnt es sich, vorsichtig zu sein, denn der erste Satz lautet: "Das Design der Harvard-Architektur-CPU ist in der Embedded-Welt üblich." Wenn man das tatsächliche Design der Harvard Mark I studiert, erkennt man schnell, dass nicht das CPU-Design wichtig war, sondern die strikte physische Trennung zwischen Anweisungen und Daten - von ihren jeweiligen Speichern bis zur Ausführung, die es in keiner mir bekannten aktuellen Architektur gibt. In diesem Papier geht es um die "modifizierte Harvard-Architektur".

2 Stimmen

@avgvstvs: Einige DSPs oder Mikrocontroller sind wirklich Harvard, mit getrennten Bussen für Befehlsspeicher und Daten. Die Idee ist, dass sie Code aus dem ROM ausführen und etwas Scratch-RAM haben. Sogar ARM9 hatte offenbar separate externe Busse (die so verbunden werden könnten, dass ein modifiziertes Harvard und nicht Harvard entsteht). Wenn der Wechsel zwischen Daten- und Anweisungsspeicher das Schreiben auf die Festplatte und das erneute Lesen in den anderen Speicher erfordert, würden die meisten Leute das wohl als Harvard und nicht als modifizierten Harvard bezeichnen. (Obwohl modifiziertes Harvard mehr umfasst als nur geteiltes L1)

1 Stimmen

Ich möchte noch einmal darauf hinweisen, dass der Mark I nicht einfach nur am Bus getrennt war, sondern eine vollständige Trennung mit getrennten Speichern für Daten und Befehle vorlag. Vielleicht haben die meisten Leute würde ein gemeinsam genutztes ROM immer noch als "Harvard" betrachten, aber ich tue das nicht. Der Grund, warum der fragliche Angriff erfolgreich sein konnte, ist, dass das ROM gemeinsam genutzt wurde.

0voto

sybreon Punkte 3126

Die meisten Maschinen mit Harvard-Architektur verwenden immer noch einen gemeinsamen Speicherbereich für Daten und Anweisungen außerhalb des Kerns. Es wäre also immer noch möglich, Code zu injizieren und ihn als Befehle ausführen zu lassen. Tatsächlich sind die meisten Prozessoren heute intern in Harvard-Architektur aufgebaut, auch wenn sie äußerlich wie von Neumann aussehen.

1 Stimmen

Moderne Mainstream-Maschinen (wie x86, ARM/AArch64 usw.) sind "modifizierte Harvard-Maschinen" (z. B. aufgeteilte L1d- und L1i-Caches ), um eine CPU zu beschleunigen, die sich, wie Sie sagen, wie eine von Neumann verhält. de.wikipedia.org/wiki/Modifizierte_Harvard_Architektur . Es ist weit hergeholt zu sagen, "die meisten Prozessoren sind Harvard", es sei denn, man bezieht Mikrocontroller mit getrenntem ROM und RAM mit ein, die tatsächlich Harvard sind und separate Befehle zum Lesen des Programmspeichers benötigen. x86 hat sogar einen kohärenten I-Cache, so dass die Harvardness völlig unsichtbar ist. (Aber die meisten RISCS wie AArch64 haben das nicht.)

0voto

Paul Nathan Punkte 38618

An meiner Universität fand kürzlich eine MS-Verteidigung statt, bei der genau diese Frage diskutiert wurde. Leider konnte ich nicht daran teilnehmen. Ich bin sicher, wenn Sie sich an Herrn Watts wenden, wird er bereit sein, das Thema zu besprechen.

http://www.cs.uidaho.edu/Defenses/KrisWatts.html

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X