Erst gestern haben wir anscheinend über einen Fehler in Google Pixel-Telefonen geschrieben jetzt gepatcht, mit potenziell gefährlichen Folgen.

Die Fehlersucher, verständlicherweise aufgeregt (und besorgt) über das, was sie gefunden hatten, beschlossen, dem BWAIN-Prinzip für das Maximum zu folgen und es zu einem zu machen Fehler mit einem beeindruckenden Namen: aKropalypse.

Falls Sie sich fragen, das Wort Apokalypse bedeutet wörtlich jede Art von Offenbarung, aber es wird normalerweise verwendet, um sich auf den biblischen Text zu beziehen, der als bekannt ist Offenbarung des Hl. Johannes, die das Ende der Welt darstellt.

Daher ist seine metaphorische Bedeutung in den Worten des New Oxford American Dictionary „ein Ereignis, das Zerstörung oder Schaden von gewaltigem oder katastrophalem Ausmaß mit sich bringt“.

Wir sind nicht ganz davon überzeugt, dass dieser Fehler einen solchen, ahhhh, apokalyptischen Namen verdient, aber wir sind bereit zuzugeben, dass der Name in einer Welt, in der großartig „ziemlich gut“ bedeuten kann, wahrscheinlich akzeptabel, wenn nicht völlig unannehmbar ist.

Die „Ernte“ in „aCropalypse“

Der „Crop“-Teil des Namens stammt von der Aktivität, die den Fehler höchstwahrscheinlich auslöst, genannt CVE-2023-20136 in seiner Google-Inkarnation: Zuschneiden von Fotos oder Screenshots, um sensible oder unerwünschte Teile zu entfernen, bevor Sie sie teilen.

Grob gesagt können Sie sich vorstellen, dass Sie, wenn Sie beispielsweise einen 1080 × 1980-Screenshot des gesamten Bildschirms Ihres Telefons aufgenommen haben, wahrscheinlich nicht das gesamte Bild online veröffentlichen oder das Ganze an einen Freund senden möchten.

Die meisten Leute würden es vorziehen, zumindest den oberen Teil des Screenshots abzuschneiden und so Details wie den Namen ihres Mobilfunkanbieters, das Datum und die Uhrzeit zu entfernen.

Und wenn Sie beispielsweise eine E-Mail oder einen Post in den sozialen Medien mitten in einer Liste aufnehmen, möchten Sie mit ziemlicher Sicherheit die E-Mails oder Posts verdecken, die direkt über oder direkt unter dem interessierenden Teil angezeigt werden.

Auch nach dem Zuschneiden des Bildes möchten Sie möglicherweise Teile davon redigieren (ein Fachjargon, das einen Teil eines Dokuments verdecken oder zensieren bedeutet), indem Sie beispielsweise ein schwarzes Kästchen über den Namen, die E-Mail-Adresse, die Telefonnummer oder was auch immer des Absenders ziehen .

Auf jeden Fall könnten Sie davon ausgehen, dass Sie, wenn Sie Teile des Originals herausgeschnitten, einige Details mit Farbblöcken verdeckt haben (die sich viel leichter komprimieren lassen als normale Bilddaten) und das neue Bild über dem alten gespeichert haben …

…dass das neue Bild mit ziemlicher Sicherheit kleiner, möglicherweise viel kleiner, als das Original sein würde.

Wegen all dem Zeug, das du ausgelassen hast!

Aber das ist auf Google Pixel-Handys nicht passiert, zumindest bis zum Android-Sicherheitsupdate vom März 2023.

Überschrieben, aber nicht abgeschnitten

Die neue, kleinere Bilddatei würde über den Anfang der alten geschrieben, aber die Dateigröße würde gleich bleiben, und die jetzt redundanten und unerwünschten Daten am Ende der Originaldatei würden dort bleiben, wo sie waren.

Wenn Sie diese Datei an jemand anderen gesendet haben und dieser sie mit einem herkömmlichen Bildbetrachtungs- oder -bearbeitungstool geöffnet hat, hat deren Software die Datei gelesen, bis sie einen Datenblock erreicht hat, auf dem stand: „Das ist es; Sie können jetzt aufhören und alle nachlaufenden Daten in der Datei ignorieren.“

Mit anderen Worten, der Codierungsfehler, der dazu führte, dass am Ende der Datei unerwünschte Daten zurückgelassen wurden, würde im Allgemeinen keine offensichtlichen Fehler provozieren, was vermutlich erklärt, warum der Fehler erst vor kurzem entdeckt wurde.

Aber wenn der Empfänger es mit einem neugierigeren Software-Tool wie einem Hex-Editor oder einem raffiniert modifizierten Bildeditor öffnete, wären einige Bytes bis hin zu einer riesigen Menge des Originalbildes immer noch da, über das offizielle Ende der - Bildmarkierung, die darauf wartet, erkundet und möglicherweise freigelegt zu werden.

Die meisten Screenshots werden als PNG-Dateien gespeichert, kurz für tragbare Netzwerkgrafiken, und werden intern mit einem allgemein bekannten Komprimierungsalgorithmus komprimiert deflate.

Die übrig gebliebenen Daten sehen daher nicht offensichtlich wie Zeilen und Spalten von Pixeln aus und können nicht direkt von herkömmlichen Entpackwerkzeugen dekomprimiert werden, die den komprimierten Datenstrom als beschädigt betrachten, was er ist, und normalerweise ablehnen überhaupt auszupacken.

Jedoch müssen auch deflate Die Komprimierung komprimiert ihre Eingabedaten normalerweise als eine Folge von Blöcken und blickt nur so weit in die Eingabe für wiederholten Text zurück (höchstens 32 KByte, für Übereinstimmungen mit einer Länge von maximal 258 Byte), um die zum Ausführen des Algorithmus benötigte Speichermenge zu reduzieren .

Diese Einschränkungen sind nicht nur auf die Tatsache zurückzuführen, dass das Format auf das zurückgeht 1990er-Jahre, als Speicherplatz noch viel kostbarer war als heute.

Indem Sie den Kompressor regelmäßig „neu synchronisieren“, verringern Sie auch das Risiko, absolut alles in einer komprimierten Datei zu verlieren, wenn auch nur ein paar Bytes am Anfang beschädigt werden sollten.

Eine umfangreiche Rekonstruktion kann möglich sein

Das bedeutet, dass im komprimierten PNG-Format gespeicherte Bilddateien oft weitgehend rekonstruiert werden können, selbst wenn beträchtliche Teile des Originals überschrieben oder anderweitig zerstört werden.

Und wenn Sie von Bildfragmenten sprechen, die aus einer beschnittenen oder geschwärzten Datei rekonstruiert werden können …

… besteht durchaus die Möglichkeit, dass die übrig gebliebenen Daten am Ende, die eigentlich abgehackt werden sollten, wiederherstellbare Bildanteile enthalten Enthüllen Sie genau die Teile, die Sie dauerhaft aus dem Bild entfernen wollten!

Sie könnten Glück haben, um sicher zu sein: Wenn das Bild Zeile für Zeile gespeichert wird (also die Daten für den oberen Rand des Bildes nahe am Anfang der Datei und die unteren am Ende liegen) und Sie abschneiden Oben im Bild erhalten Sie wahrscheinlich ein neues Bild, das aus der unteren Hälfte des alten Bildes im „offiziellen“ Teil der Datei besteht und die untere Hälfte in den übrig gebliebenen Daten wiederholt wird, die vorhanden sein sollten abgehackt, war es aber nicht.

Aber wenn Sie den unteren Rand des Bildes abschneiden, wird in der neuen Datei der alte obere Teil „offiziell“ neu kodiert und über den Anfang geschrieben, und die abgeschnittene untere Hälfte des Bildes genau dort zurückgelassen, wo es vorher war, am inoffiziellen Ende der neuen Datei, die darauf wartet, von einem Angreifer extrahiert zu werden.

Auch Windows 11 betroffen

Nun, der Deal ist, dass dieses Problem, dass Dateien nicht abgeschnitten werden, wenn sie durch eine neue Version ersetzt werden, auch unter Windows 11 gilt, wo die Snipping Tool, wie die Google Pixel Markup-App, ermöglicht es Ihnen, ein Bild zuzuschneiden, ohne die Datei, in der es gespeichert ist, korrekt zuzuschneiden.

Hier ist zum Beispiel eine PNG-Datei, die wir mit GIMP erstellt und mit einem minimalen Satz von Headern und ohne Komprimierung gespeichert haben:

Die Datei besteht aus 320 × 200 Pixeln mit 8-Bit-RGB-Daten (drei Bytes pro Pixel), sodass die Datei 320 × 200 × 3 Bytes lang ist (192,000), plus ein paar hundert Bytes Header und andere begrenzte Metadaten für eine Gesamtgröße von 192,590 Bytes .

Im beispielhaften Hex-Dump unten sehen Sie, dass die Daten 0x20F04E Bytes lang sind, was 192,590 Dezimalzahlen entspricht:

Wir haben es dann so klein geschnitten, wie es das Snipping Tool zulässt (48 × 48 Pixel scheinen das Minimum zu sein) und es wieder über sich selbst gespeichert, aber die „neue“ Datei hatte am Ende die gleiche Größe wie die unkomprimierte 320 × 200-Datei!

Im Hex-Dump unten ist der oben rosa hervorgehobene Teil die Gesamtheit dessen, was die zugeschnittene Datei enthalten soll, mit einer Länge von 0xBD Bytes oder 189 in Dezimalzahl.

Die neuen Daten enden mit einem IEND Datenblock, wo die neue Datei enden sollte, aber Sie können sehen, dass sie mit den übrig gebliebenen Daten von vorher fortgesetzt wird und schließlich mit einem Duplikat endet, das aber jetzt redundant ist IEND Block, der aus der alten Datei übernommen wurde, zusammen mit fast allen seinen Bilddaten:

Als wir die benutzten Speichern Schaltfläche, um es unter einem brandneuen Dateinamen auszugeben, kam die komprimierte 48×48-Datei tatsächlich mit nur 189 Bytes heraus.

Beachten Sie, wie die Daten in der Datei mit den 189 Bytes übereinstimmen, die im vorherigen Bild rosa hervorgehoben sind:

Der Fehler besteht also darin, dass beim Zurückspeichern einer Datei über einen vorhandenen Dateinamen nicht zuerst die alte Datei abgeschnitten und keine neue Datei mit der erwarteten Größe erstellt wird.

Einfach ausgedrückt, die zugeschnittene Datei ist teilweise überschrieben, eher als eigentlich ersetzt.

Wie oben erwähnt, vermuten wir, dass dieser Fehler bisher noch niemandem aufgefallen ist, da Bildbetrachtungs- und -bearbeitungsprogramme bis zum ersten Mal gelesen haben IEND -Tag (Sie können dies in der unteren rechten Ecke des obigen Screenshots sehen) und ignorieren Sie am Ende stillschweigend alle zusätzlichen Dinge, ohne Anomalien oder Fehler zu melden.

Was ist zu tun?

• Wenn Sie ein Windows 11-Benutzer sind. Speichern Sie zugeschnittene Dateien, die mit dem Snipping Tool erstellt wurden, immer unter einem neuen Dateinamen, damit keine ursprünglichen Inhalte darin zurückbleiben können.
• Wenn Sie ein Programmierer sind. Überprüfen Sie überall, wo Sie „neue“ Dateien erstellen, indem Sie alte überschreiben, um sicherzustellen, dass Sie die Originaldateien wirklich abschneiden, wenn Sie sie zum Umschreiben öffnen. Oder erstellen Sie neue Dateien immer nur, indem Sie sie zuerst in einer wirklich neuen Datei speichern (verwenden Sie einen sicher generierten eindeutigen Dateinamen), dann explizit die Originaldatei löschen und die neue umbenennen.

Übrigens haben wir Microsoft Paint getestet, und soweit wir sehen können, erstellt dieses Programm beschnittene Dateien ohne übrig gebliebene Daten von früher, unabhängig davon, ob Sie es verwenden Speichern (um eine vorhandene Datei zu ersetzen) oder Speichern unter (um ein neues zu produzieren).

ERFAHREN SIE SELBST MEHR ÜBER DIE ÖFFNUNGSMODI VON DATEIEN

Kompilieren Sie diesen Code und führen Sie ihn aus.

Unter Windows können Sie verwenden minimalistisch-C, unser eigenes kuratierter Bau der freien Tiny C-Compiler, wenn Sie kein Entwicklungssystem installiert haben.

Es ist unter 500 KB groß (!), einschließlich des vollständigen Quellcodes, verglichen mit jeweils Gigabyte für Visual Studio oder Clang für Windows.

#enthalten #enthalten int main(void) { char* az = "ABCDEFGHIJLKMNOPQRSTUVWXYZ"; int fd; // Erstellen Sie eine Datei mit AZ darin // Oktal 0666 bedeutet "Lesen/Schreiben für alle" // O_CREAT bedeutet Erstellen, falls erforderlich fd = open("blah1.txt",O_WRONLY+O_CREAT,0666); schreiben (fd, az, 26); schließen (fd); // Eine weitere Datei mit AZ darin erstellen fd = open("blah2.txt",O_WRONLY+O_CREAT,0666); schreiben (fd, az, 26); schließen (fd); // 10 Bytes schreiben ohne gesetztes O_TRUNC // Die restlichen 16 Bytes sollen bleiben fd = open("blah1.txt",O_WRONLY); schreiben(fd,"----------",10); schließen (fd); // Schreibe 10 Bytes *mit* gesetztem O_TRUNC // Restliche alte Daten sollen abgehackt werden fd = open("blah2.txt",O_WRONLY+O_TRUNC); schreiben(fd,"==========",10); schließen (fd); 0 zurückgeben; }

Beachten Sie den Unterschied zwischen dem Öffnen einer vorhandenen Datei zum Schreiben (O_WRONLY) mit und ohne Einstellung der O_TRUNC Flagge.

Drucken Sie den Inhalt aus blah1.txt und blah2.txt nach dem Ausführen des Testprogramms:

C:UsersduckCROP> petcc64 -stdinc -stdlib test.c Winziger C-Compiler - Copyright (C) 2001-2023 Fabrice Bellard Abgespeckt von Paul Ducklin zur Verwendung als Lernwerkzeug Version petcc64-0.9.27 [0006] - Erzeugt 64-Bit Nur PEs -> t1.c -> c:/users/duck/tcc/petccinc/fcntl.h . . . . -> C:/Windows/system32/msvcrt.dll -> C:/Windows/system32/kernel32.dll --------------------- ----- virt Dateigröße Abschnitt 1000 200 2a0 .text 2000 600 1cc .data 3000 800 18 .pdata --------------------- ----- <- t1.exe (2560 Byte) C:UsersduckCROP> t1.exe C:UsersduckCROP>dir blah*.txt Volume in Laufwerk C hat keine Bezeichnung. Seriennummer des Volumes ist C001-D00D Verzeichnis von C:UsersduckCROP 22 03:2023 Uhr 07 blah20.txt 26 1:22 Uhr 03 blah2023.txt 07 Datei(en) 20 Byte C:UsersduckCROP> Typ blah10.txt ----------KLMNOPQRSTUVWXYZ C:UsersduckCROP> geben Sie blah2.txt ========== ein

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
• Quelle: https://nakedsecurity.sophos.com/2023/03/22/windows-11-also-vulnerable-to-acropalypse-image-data-leakage/