Kann ich in ein Image eingebettete Anweisungen an ein Ziel senden, wenn ich seine CPU-Architektur kenne?
Kann ich in ein Image eingebettete Anweisungen an ein Ziel senden, wenn ich seine CPU-Architektur kenne?
Andere Antworten geben eine gute technische Erklärung, aber lassen Sie mich eine Analogie versuchen:
Bitte senden Sie Ihre Kreditkartennummer an scam@example.com
Hast du es gelesen?
Hast du es getan?
Es ist mehr oder weniger das gleiche gilt für deine CPU. Etwas zu lesen ist nicht dasselbe wie es auszuführen.
CPU-Anweisungen werden in sogenannten Opcodes gegeben, und Sie haben Recht, dass diese genau wie Ihr Image im Speicher gespeichert sind. Sie leben jedoch in konzeptionell unterschiedlichen "Speicherbereichen".
Sie können sich beispielsweise einen Opcode "read" (0x01) vorstellen, der ein Byte der Eingabe von stdin liest und irgendwo ablegt, sowie einen anderen Operanden "add" (0x02), das zwei Bytes hinzufügt. Einige Opcodes können Argumente annehmen, daher geben wir unseren Beispiel-Opcodes einige: Der "Lese" -Opcode verwendet einen Operanden zum Speichern des gelesenen Bytes und der "Hinzufügen" -Operand drei Operanden: zwei zum Lesen der Eingaben und eine, in die das Ergebnis geschrieben werden soll.
0x01 a1 // ein Byte in den Speicherort 0xa10x01 a2 lesen // ein Byte in den Speicherort 0xa20x02 a1 a2 a3 lesen // die Bytes lesen Fügen Sie sie an den Positionen 0xa1 und 0xa2 hinzu, // und schreiben Sie das Ergebnis an Position 0xa3.
Dies ist typisch für die Funktionsweise vieler Anweisungen: Die meisten von ihnen arbeiten nur mit Daten, die sich im Speicher befinden und einige von ihnen speichern neue Daten von außen in den Speicher (in diesem Beispiel vom Lesen von stdin oder vom Lesen einer Datei oder einer Netzwerkschnittstelle).
Während es stimmt, dass die Anweisungen und die Daten Sie arbeiten beide im Speicher, das Programm führt nur die Anweisungen aus. Es ist die Aufgabe der CPU, des Betriebssystems und des Programms, dafür zu sorgen, dass dies geschieht. Wenn sie fehlschlagen, können Sie tatsächlich Daten in den Ausführungsbereich laden, und es handelt sich um einen schwerwiegenden Sicherheitsfehler. Pufferüberläufe sind wahrscheinlich das bekannteste Beispiel für einen solchen Fehler. Abgesehen von diesen Arten von Fehlern können Sie sich den Datenraum und den Ausführungsraum im Wesentlichen als separate Teile der CPU vorstellen.
In einem Spielzeugcomputer sieht der Speicher anhand des obigen Beispiels möglicherweise so aus :
(loc) | Anfänglich | Nach op 1 | Nach op 2 | Nach op 3 | 0x00 | * 01 a1 | 01 a1 | 01 a1 | 01 a1 | 0x02 | 01 a2 | * 01 a2 | 01 a2 | 01 a2 |
0x04 | 02 a1 a2 a3 | 02 a1 a2 a3 | * 02 a1 a2 a3 | 02 a1 a2 a3 | 0x08 | 99 | 99 | 99 | * 99 | ... 0xa1 | 00 | 03 | 03 | 03 | 0xa2 | 00 | 00 | 04 | 04 | 0xa3 | 00 | 00 | 00 | 07 |
In diesem Beispiel zeigt das Sternchen ( *
) auf den nächsten Opcode, der ausgeführt wird. Die Spalte ganz links gibt den Startspeicherort für diese Zeile an. So zeigt uns die zweite Zeile beispielsweise zwei Bytes Speicher (mit den Werten 01
und a2
) an den Stellen 0x02 (explizit in der linken Spalte) und 0x03.
(Bitte haben Sie Verständnis dafür, dass dies alles eine große Vereinfachung ist. In einem realen Computer kann beispielsweise der Speicher verschachtelt werden - Sie haben nicht nur einen Teil der Anweisungen und einen Teil von allem anderen sollte jedoch für diese Antwort gut genug sein.)
Beachten Sie, dass sich beim Ausführen des Programms der Speicher in den Bereichen 0xa1 - 0xa3 ändert, der Speicher in 0x00 - 0x08 jedoch nicht. Die Daten in 0x00 - 0x08 sind die ausführbare Datei unseres Programms, während der Speicher in den Bereichen 0xa1 - 0xa3 der Speicher ist, den das Programm für die Zahlenverarbeitung verwendet.
Um also zu Ihrem Beispiel zurückzukehren: Die Daten in Ihrem JPEG werden von Opcodes in den Speicher geladen und von Opcodes manipuliert, aber nicht in denselben Bereich im Speicher geladen. Im obigen Beispiel befanden sich die beiden Werte 0x03 und 0x04 nie im Opcode-Bereich, was von der CPU ausgeführt wird. Sie befanden sich nur in dem Bereich, aus dem die Opcodes lesen und schreiben. Solange Sie keinen Fehler (wie einen Pufferüberlauf) gefunden haben, mit dem Sie Daten in diesen Opcode-Bereich schreiben können, werden Ihre Anweisungen nicht ausgeführt. Dies sind nur die Daten, die durch die Ausführung des Programms manipuliert werden.
Können Sie sie senden? Ja natürlich. Bauen Sie sie einfach zusammen und kleben Sie sie irgendwo in die Bilddatei.
Wird das Ziel sie ausführen? Nein, es sei denn, Sie haben bereits die Kontrolle über das Ziel (und können dort ein Programm zum Lesen und Ausführen platzieren), oder Sie finden einen Exploit in einem Bildbetrachter und lassen das Bild darin laden.
Sie könnten, wenn Ihr Ziel eine Version von Internet Explorer vor August 2005 verwendet, um ein JPG anzuzeigen. Oder wenn sie ein PNG in Windows Media Player unter Windows 98 ohne installierte Sicherheitsupdates öffnen wollten. Und so weiter.
Es gab eine Menge alter Software, die Fehler aufwies, wenn Sie eine Bilddatei erstellt haben, in der der erste Teil der Bilddatei empörend über die Größe und Position des Pixels lag Daten in der Datei könnte die Software etwas falsch machen und versehentlich an der falschen Adresse zum Code springen oder Daten aus der Datei an einer Stelle schreiben, an der sich der Programmcode befinden sollte. Ich erinnere mich, dass einer dieser Hacks eine Datei betraf, deren Header behauptete, das Bild habe eine negative Größe. Mit neueren Versionen von Internet Explorer oder Edge ist dies wahrscheinlich nicht möglich, da jeder das Problem jetzt kennt und Microsoft sein Bestes getan hat, um es zu beheben.
Die heutigen Betriebssysteme verfügen über einige Schutzmaßnahmen um es schwierig (aber nicht völlig unmöglich) zu machen, etwas wirklich Schlechtes zu erreichen, wenn Sie einen neuen Weg finden, ein Programm mit einer solchen Methode zu hacken. Speicherbereiche können so eingestellt werden, dass sie nicht ausgeführt werden können. Programme verfügen über separate virtuelle Adressräume, sodass sie nicht versehentlich auf den Speicher des anderen zugreifen können. Einige Betriebssystemkomponenten werden an unvorhersehbaren Speicherorten geladen, sodass böswilliger Code sie nicht einfach finden und verwenden kann.
Nein. Bilddateien wie JPEG-Dateien führen keinen Code aus, sondern werden einfach gerendert und angezeigt.
Wenn Sie einige Informationen in einer Datei mit dem Namen Steganography ausblenden möchten, die jedoch nur Informationen verbirgt, ist dies nicht der Fall Führen Sie alle Anweisungen aus.
Damit eine Datei Code ausführen kann, muss sie eine ausführbare Datei sein oder von einem anderen Programm ausgeführt werden, das die Datei liest und dann die Befehle in der Datei ausführt.
In diesem Fall ist der seltene Fall, in dem ein Bild zur Ausführung von Code führen kann, ein Fehler in der Software, der das Bild basierend auf der Datei gerendert hat. Dies ist in der Vergangenheit passiert, aber es ist äußerst selten. Für alle praktischen Zwecke kann ein Bild keine Anweisungen ausführen.
Dies ist natürlich bei PDFs, Adobe Flash usw. nicht der Fall.
Sie können, WENN Sie auch wissen, welcher Software-Stack das Image auf der Empfangsseite berührt, UND WENN dieser Software-Stack ungelöste Sicherheitslücken aufweist.
Das einfache Einfügen der Anweisungen in die JPEG-Datei führt zu nichts.
Wenn jedoch eine Möglichkeit bekannt ist, eine bestimmte genaue Implementierung des JPEG-Readers in einer fehlerhaften JPEG-Datei in gewisser Weise zum Absturz zu bringen dass Daten aus der Bilddatei kopiert werden, zu der diese Daten nicht gehören (z. B. über Variablen, die Programmsteuerungsflussinformationen wie Funktionszeiger oder Rücksprungadressen enthalten), und dass Gegenmaßnahmen auf Betriebssystem- oder Hardwareebene (z. B. DEP) nicht aufhören dass es eine realistische Chance gibt. Solche Schwachstellen waren in realen Implementierungen vorhanden (und existieren in älteren Implementierungen).
Die Kurzversion ist nein, da Computer (sollten) den Unterschied zwischen Daten und Anweisungen kennen. Das Schlimmste, was Sie mit einem JPEG tun sollten, ist so etwas wie eine Zip-Bombe oder etwas, das einige JPEG-Dekomprimierungsroutinen zum Absturz bringt. Ein Programm zum Laden von &, das ein JPEG anzeigt, versucht nicht, Daten in der Datei auszuführen, sondern nur zu lesen und zu verarbeiten. Wenn es auf unerwartet nicht JPEG-Daten trifft, wird es entweder gestoppt oder stürzt ab oder zeigt nur ein an wirklich durcheinander gebrachtes Bild.
JEDOCH (manchmal sehe ich Sie an, Microsoft) versuchen Leute, hilfreiche Software zu schreiben, die anfällig sein kann, indem sie (zum Beispiel) versuchen, &-Anzeige-E-Mail-Anhänge automatisch zu laden Erstellen Sie Dokumentformate, die Skripte / Makros usw. enthalten können. Hier kann eine schädliche Datei Schaden anrichten.
Das klassische (und hoffentlich nicht mehr existierende / geschützte) Beispiel sind E-Mail-Anhänge So etwas wie .jpg.exe
, wobei die Datei wirklich eine ausführbare Datei ist und Windows sie als solche behandelt, aber weil Windows die Erweiterung (das Ausblenden des letzten .exe-Teils) verbirgt Siehe file.jpg
und klicken Sie darauf, wodurch das Betriebssystem es ausführt.
Es ist der Unterschied zwischen dem Lesen eines Buches und dem Handeln von o ut den Inhalt des Buches - wenn das Buch "Geh und schlag jemanden" sagt, wirst du es nicht tun, weil die Wörter (Daten) im Buch dein Gehirn nicht kontrollieren, obwohl dein Gehirn diese Daten verarbeitet.