Jeszcze wczoraj pisaliśmy o błędzie w telefonach Google Pixel, który podobno został już załatany i może mieć niebezpieczne konsekwencje.

Twórcy błędów, co zrozumiałe podekscytowani (i zaniepokojeni) tym, co znaleźli, postanowili maksymalnie wykorzystać zasadę BWAIN, przekształcając ją w Błąd o imponującej nazwie: a Cropalypse.

Jeśli się zastanawiasz, słowo apokalipsa oznacza dosłownie każdy rodzaj objawienia, ale zwykle jest używane w odniesieniu do tekstu biblijnego znanego jako Objawienie św. Janaktóry przedstawia koniec świata.

Toteż jego metaforyczne znaczenie, jak podaje New Oxford American Dictionary, to „wydarzenie obejmujące zniszczenie lub zniszczenie na zdumiewającą lub katastrofalną skalę”.

Nie jesteśmy do końca przekonani, czy ten błąd zasługuje na tak, ach, apokaliptyczna nazwa, ale jesteśmy skłonni przyznać, że w świecie, w którym „niesamowity” może oznaczać „całkiem dobry”, nazwa ta jest prawdopodobnie akceptowalna, jeśli nie całkowicie nienaganna.

„Uprawa” w „aCropalypse”

Część „przycinania” nazwy pochodzi od działania, które najprawdopodobniej wywoła błąd, dubbingowane CVE-2023-20136 w swoim wcieleniu Google: kadrowanie zdjęć lub zrzutów ekranu w celu usunięcia wrażliwych lub niechcianych części przed ich udostępnieniem.

Mówiąc luźno, możesz sobie wyobrazić, że gdybyś zrobił, powiedzmy, zrzut ekranu 1080 × 1980 całego ekranu swojego telefonu, prawdopodobnie nie chciałbyś opublikować całego obrazu online lub wysłać go w całości znajomemu.

Większość ludzi wolałaby przyciąć przynajmniej górę zrzutu ekranu, usuwając w ten sposób szczegóły, takie jak nazwa operatora sieci komórkowej, data i godzina.

A jeśli robisz zdjęcie, powiedzmy, e-maila lub wpisu w mediach społecznościowych w środku listy, prawie na pewno chciałbyś zasłonić e-maile lub posty, które pojawiły się tuż nad lub tuż pod częścią zainteresowania.

Nawet po przycięciu obrazu możesz również chcieć zredagować jego części (słowo żargonowe oznaczające zaciemnienie lub cenzurę części dokumentu), na przykład umieszczając czarną skrzynkę na imieniu i nazwisku nadawcy, adresie e-mail, numerze telefonu lub cokolwiek .

W każdym razie możesz założyć, że jeśli wytniesz fragmenty oryginału, przesłonisz niektóre szczegóły blokami jednolitego koloru (które kompresują się znacznie łatwiej niż zwykłe dane obrazu) i zapiszesz nowy obraz na starym…

…że nowy obraz prawie na pewno byłby mniejszy, być może znacznie mniejszy niż oryginał.

Z powodu wszystkich rzeczy, które pominąłeś!

Ale tak się nie stało na telefonach Google Pixel, przynajmniej do aktualizacji zabezpieczeń Androida z marca 2023 r.

Nadpisane, ale nie obcięte

Nowy, mniejszy plik obrazu zostałby zapisany na początku starego, ale rozmiar pliku pozostałby taki sam, a niepotrzebne i niepotrzebne dane na końcu oryginalnego pliku pozostałyby tam, gdzie były.

Jeśli wysłałeś ten plik do kogoś innego, a ta osoba otworzyła go za pomocą konwencjonalnego narzędzia do przeglądania lub edycji obrazu, jego oprogramowanie odczytałoby plik, dopóki nie osiągnął fragmentu danych, który powiedział: „To wszystko; możesz teraz przerwać i zignorować wszelkie końcowe dane w pliku”.

Innymi słowy, wada kodowania, która spowodowała pozostawienie niechcianych danych na końcu pliku, generalnie nie powodowałaby żadnych oczywistych błędów, co prawdopodobnie wyjaśnia, dlaczego błąd został zauważony dopiero niedawno.

Ale jeśli odbiorca otworzyłby go za pomocą bardziej dociekliwego narzędzia programowego, takiego jak edytor szesnastkowy lub sprytnie zmodyfikowany edytor obrazów, od kilku bajtów do ogromnej ilości oryginalnego obrazu nadal by tam był, poza oficjalnym końcem- znacznik obrazu, który czeka na odkrycie i potencjalnie odsłonięcie.

Większość zrzutów ekranu jest zapisywana jako pliki PNG, skrót od Przenośna Grafika Sieciowai są wewnętrznie kompresowane przy użyciu algorytmu kompresji znanego powszechnie jako siadać.

Dlatego pozostałe dane nie wyglądają oczywiście jak wiersze i kolumny pikseli i nie można ich bezpośrednio zdekompresować za pomocą konwencjonalnych narzędzi do rozpakowywania, które uznają skompresowany strumień danych za uszkodzony, czym jest, i zazwyczaj odmówią spróbować go w ogóle rozpakować.

Ale siadać kompresja zwykle ściska dane wejściowe jako sekwencję bloków, patrząc wstecz tylko do tej pory na dane wejściowe dla powtarzającego się tekstu (maksymalnie 32 KB, dla dopasowań o długości co najwyżej 258 bajtów) w celu zmniejszenia ilości pamięci potrzebnej do uruchomienia algorytmu .

Ograniczenia te wynikają nie tylko z faktu, że format pochodzi z lat 90., kiedy przestrzeń pamięci była znacznie cenniejsza niż obecnie.

Regularnie „ponownie synchronizując” kompresor zmniejszasz również ryzyko utraty absolutnie wszystkiego w skompresowanym pliku, jeśli nawet kilka bajtów na początku ulegnie uszkodzeniu.

Możliwa jest znaczna rekonstrukcja

Oznacza to, że pliki obrazów przechowywane w skompresowanym formacie PNG często można w znacznym stopniu zrekonstruować, nawet jeśli duże fragmenty oryginału zostaną nadpisane lub zniszczone w inny sposób.

A jeśli mówisz o fragmentach obrazu, które można zrekonstruować z pliku, który został przycięty lub zredagowany…

…wyraźnie istnieje szansa, że ​​pozostałe dane na końcu, które miały zostać odcięte, będą zawierały możliwe do odzyskania fragmenty obrazu odsłaniając dokładnie te części, które zamierzałeś trwale usunąć z obrazu!

Na pewno możesz mieć szczęście: jeśli obraz jest przechowywany wiersz po wierszu (więc dane na górze obrazu są blisko początku pliku, a dół na końcu), a ty przycinasz górnej części obrazu, prawdopodobnie otrzymasz nowy obraz składający się z dolnej połowy starego obrazu w „oficjalnej” części pliku oraz dolnej połowy powtórzonej w pozostałych danych, które miały zostać odcięty, ale nie był.

Ale jeśli przytniesz dolną część obrazu, nowy plik będzie miał starą górną część „oficjalnie” ponownie zakodowaną i zapisaną na początku, a przyciętą dolną połowę obrazu pozostawił dokładnie tam, gdzie był wcześniejw nieoficjalnym końcu nowego pliku, czekającego na wyodrębnienie przez atakującego.

Dotyczy to również systemu Windows 11

Cóż, sprawa polega na tym, że ten problem plików, które nie są obcinane, gdy są zastępowane nową wersją, dotyczy również systemu Windows 11, gdzie Narzędzie do wycinaniapodobnie jak aplikacja Google Pixel Markup, pozwala przyciąć obraz bez prawidłowego przycinania pliku, w którym został zapisany.

Na przykład, oto plik PNG, który utworzyliśmy za pomocą GIMP-a i zapisaliśmy z minimalnym zestawem nagłówków i bez kompresji:

Plik ma wymiary 320 × 200 pikseli 8-bitowych danych RGB (trzy bajty na piksel), więc plik ma długość 320 x 200 x 3 bajty (192 000) plus kilkaset bajtów nagłówka i innych ograniczonych metadanych, co daje łączny rozmiar 192 590 bajtów .

Na ilustracyjnym zrzucie szesnastkowym poniżej widać, że dane mają długość 0x20F04E bajtów, czyli 192 590 dziesiętnie:

Następnie przycięliśmy go tak mały, jak pozwala na to narzędzie wycinania (48 × 48 pikseli wydaje się być minimum) i zapisaliśmy go z powrotem na sobie, ale „nowy” plik zakończył się tym samym rozmiarem, co nieskompresowany plik 320 × 200!

Na poniższym zrzucie szesnastkowym część podświetlona na różowo u góry to całość tego, co powinien zawierać przycięty plik, o długości 0xBD lub 189 dziesiętnie.

Nowe dane kończą się na IEND blok danych, w którym powinien się kończyć nowy plik, ale widać, że kontynuuje on z pozostałymi danymi z poprzedniego, ostatecznie kończąc na duplikacie, ale teraz nadmiarowym IEND blok, który został przeniesiony ze starego pliku, wraz z prawie wszystkimi jego danymi obrazu:

Kiedy korzystaliśmy z Ratować przycisk, aby zapisać go pod zupełnie nową nazwą pliku, skompresowany plik 48 × 48 rzeczywiście wyszedł na długość zaledwie 189 bajtów.

Zwróć uwagę, jak dane w pliku pasują do 189 bajtów zaznaczonych na różowo na poprzednim obrazie:

Błąd polega zatem na tym, że zapisanie pliku z powrotem na istniejącej nazwie pliku nie powoduje najpierw obcięcia starego pliku i nie tworzy nowego pliku o oczekiwanym rozmiarze.

Mówiąc najprościej, przycięty plik jest częściowo nadpisanea nie faktycznie zastąpiony.

Jak wspomniano powyżej, domyślamy się, że nikt do tej pory nie zauważył tej wady, ponieważ programy do przeglądania i edycji zdjęć czytały do ​​​​pierwszego IEND tag (możesz to zobaczyć w prawym dolnym rogu powyższego zrzutu ekranu) i po cichu zignoruj ​​wszystkie dodatkowe rzeczy na końcu, nie zgłaszając żadnych anomalii ani błędów.

Co robić?

• Jeśli jesteś użytkownikiem systemu Windows 11. Zawsze zapisuj przycięte pliki utworzone za pomocą narzędzia wycinania pod nową nazwą, aby nie zawierały oryginalnej treści, którą można by pozostawić.
• Jeśli jesteś programistą. Przeglądaj wszędzie, gdzie tworzysz „nowe” pliki, nadpisując stare, aby upewnić się, że naprawdę obcinasz oryginalne pliki, gdy otwierasz je w celu przepisania. Albo zawsze twórz nowe pliki, najpierw zapisując je w naprawdę nowym pliku (użyj bezpiecznie wygenerowanej unikalnej nazwy pliku), a następnie jawnie usuwając oryginalny plik i zmieniając nazwę nowego.

Nawiasem mówiąc, przetestowaliśmy program Microsoft Paint i z tego, co wiemy, program ten utworzy wykadrowane pliki bez resztek danych z poprzedniego okresu, niezależnie od tego, czy używasz Ratować (aby zastąpić istniejący plik) lub Zapisz jako (aby wyprodukować nowy).

DOWIEDZ SIEBIE O TRYBACH OTWIERANIA PLIKÓW

Skompiluj ten kod i uruchom go.

W systemie Windows możesz użyć minimalisti-C, naszej własnej, wyselekcjonowanej darmowej wersji Mały kompilator Cjeśli nie masz zainstalowanego systemu programistycznego.

Ma mniej niż 500 KB (!), łącznie z pełnym kodem źródłowym, w porównaniu z gigabajtami dla Visual Studio lub Clang dla Windows.

#include <fcntl.h>
#include <stdio.h>

int main(void) {
   char* az = "ABCDEFGHIJLKMNOPQRSTUVWXYZ";
   int  fd;

   // Create a file with A-Z in it
   // Octal 0666 means "read/write for everyone"
   // O_CREAT means create if needed
   fd = open("blah1.txt",O_WRONLY+O_CREAT,0666);
   write(fd,az,26);
   close(fd);

   // Create another file with A-Z in it
   fd = open("blah2.txt",O_WRONLY+O_CREAT,0666);
   write(fd,az,26);
   close(fd);

   // Write 10 bytes without O_TRUNC set
   // The left-over 16 bytes should remain
   fd = open("blah1.txt",O_WRONLY);
   write(fd,"----------",10);
   close(fd);

   // Write 10 bytes *with* O_TRUNC set
   // Left-over old data should be chopped off
   fd = open("blah2.txt",O_WRONLY+O_TRUNC);
   write(fd,"==========",10);
   close(fd);   

   return 0;
}

Zwróć uwagę na różnicę między otwarciem istniejącego pliku do zapisu (O_WRONLY) z ustawieniem i bez ustawienia O_TRUNC flaga.

Wydrukuj zawartość blah1.txt I blah2.txt po uruchomieniu programu testowego:

C:\Users\duck\CROP> petcc64 -stdinc -stdlib test.c
Tiny C Compiler - Copyright (C) 2001-2023 Fabrice Bellard
Stripped down by Paul Ducklin for use as a learning tool
Version petcc64-0.9.27 [0006] - Generates 64-bit PEs only
-> t1.c
-> c:/users/duck/tcc/petccinc/fcntl.h
 . . . .
-> C:/Windows/system32/msvcrt.dll
-> C:/Windows/system32/kernel32.dll
-------------------------------
  virt   file   size  section
  1000    200    2a0  .text
  2000    600    1cc  .data
  3000    800     18  .pdata
-------------------------------
<- t1.exe (2560 bytes)

C:\Users\duck\CROP> t1.exe

C:\Users\duck\CROP>dir blah*.txt
Volume in drive C has no label.
Volume Serial Number is C001-D00D

 Directory of C:\Users\duck\CROP

22/03/2023  07:20 pm                26 blah1.txt
22/03/2023  07:20 pm                10 blah2.txt
               2 File(s)             36 bytes

C:\Users\duck\CROP> type blah1.txt
----------KLMNOPQRSTUVWXYZ

C:\Users\duck\CROP> type blah2.txt
==========