Pytanie:
Czy po prostu rozpakowanie obrazu JPEG może wywołać exploita?
JDługosz
2015-08-27 00:01:00 UTC
view on stackexchange narkive permalink

Powieść Daemon jest często chwalona za realistyczne przedstawienie, a nie tylko za mieszanie modnych frazesów.

Wydało mi się to jednak nierealne:

E-mail Gragga zawierał zatruty plik JPEG z logo firmy brokerskiej. Pliki JPEG były skompresowanymi plikami graficznymi. Gdy użytkownik przeglądał wiadomość e-mail, system operacyjny uruchamiał algorytm dekompresji, aby wyświetlić grafikę na ekranie; to właśnie ten algorytm dekompresji wykonał złośliwy skrypt Gragga i pozwolił mu wślizgnąć się do systemu użytkownika - dając mu pełny dostęp. Dostępna była łatka usuwająca lukę w dekompresji, ale starsi, bogaci ludzie zazwyczaj nie mieli pojęcia o poprawkach bezpieczeństwa.

Czy istnieje coś takiego? Czy ten opis jest oparty na jakimś prawdziwym exploicie?

Został opublikowany w grudniu 2006 roku.

Czy rozsądne jest stwierdzenie, że „system operacyjny” dekompresował obraz, aby go wyrenderować?

Zauważ, że nie ma to nic wspólnego z bezpieczeństwem skryptów przesyłających obrazy PHP. Pytam o proces dekodowania przy wyświetlaniu JPEG , a nie o skrypty pobierające dane od zdalnych użytkowników ani o pliki o błędnych nazwach .jpeg . Powielone oznaczenie, na które odpowiadam, wygląda słabo nawet w przypadku dopasowania hasła; naprawdę nic podobnego poza wspominaniem o plikach graficznych.

Niestety prawie każdy format może zostać zatruty. Nawet niektóre uszkodzone pliki mogą spowodować awarię wbudowanych procedur dekompresji i / lub dekodowania.
Nie mogę znaleźć żadnych dowodów w Internecie, ale pamiętam, że kiedyś otrzymałem obraz `JPG`, który otworzył moją tacę CD (było to ponad 12 lat temu w systemie Windows XP).
Złośliwe oprogramowanie w plikach obrazów jest popularne w fikcji od czasu, gdy exploit GDI + w 2004 roku był prawdziwym przypadkiem. Ten przykład jest całkiem wiarygodny. Niektórzy mniej. Być może gorzej było w przypadku * Bones *, gdzie ktoś wyrył fraktalny obraz w kości ofiary zabójstwa, który przejął kontrolę nad siecią bohaterów, gdy przesyłali zdjęcia. To spowodowało ból mózgu.
To nie wystarczy do prawdziwej odpowiedzi, ale inny format obrazu, WMF, w rzeczywistości pozwolił na uruchomienie dowolnego kodu * zgodnie z projektem *. Został zaprojektowany do inteligentnej grafiki wektorowej w czasach 16-bitowego systemu Windows i uznano go wówczas za dobry kompromis. Szybko do przodu, a internet sprawia, że ​​jest to brutalna dziura w zabezpieczeniach. Wystąpił również exploit dla plików TTF (czcionek). Jest całkowicie możliwe, że niektóre parsery JPG mogą mieć w ten sam sposób lukę w zabezpieczeniach typu exploitabel.
Jeśli jpeg nie pozwala na dowolny kod zgodnie z projektem, w jaki sposób może mieć ten sam rodzaj luki w zabezpieczeniach?
ODPOWIEDŹ, że otwieracz do szuflad CD nie był JPEG - to był skrypt VBS, który IE wykonał pomimo rozszerzenia pliku jpeg.
To była powszechna metoda rootowania pierwszej wersji iPhone'a.
@arivero "to" odnosi się do ...? (Exploit dekodujący lub coś w poprzednim komentarzu)
@user158037 dzięki, nie pamiętałem, czy to przeglądarka obrazów, czy IE miała tę wadę.
@JDługosz er ... „it” odnosi się do Twojego pierwotnego pytania „dekompresowanie obrazu JPEG”.
Samo wyświetlenie strony z plikiem jpeg spowodowałoby zrootowanie telefonu? Jak przydatne. Masz do tego odnośnik?
Jestem mile zaskoczony, widząc tutaj Daemona. Czytałem to kilka lat temu i to niesamowite, jak bardzo trzymał się realistycznej, wcześniej istniejącej technologii. W rzeczywistości w zeszłym tygodniu wpadłem na hipersoniczny system dźwiękowy (rodzaj systemu dźwiękowego, który był w domu Sobola) w Best Buy i było to całkiem interesujące.
możliwy duplikat [Czy do obrazu można dołączyć złośliwe oprogramowanie?] (http://security.stackexchange.com/questions/55061/can-malware-be-attached-to-an-image/)
Jednym z exploitów wykorzystywanych na PS3 do grania w nagrane gry PS2 (nie żartujemy) było otwarcie specjalnie spreparowanego obrazu TIFF w wersji 1.75 oprogramowania układowego. Istnieje również [luka StageFright] (http://security.stackexchange.com/questions/95165/how-exactly-does-the-stagefright-vulnerability-work-on-android) na Androidzie, która nawet nie wymaga otwieranie wiadomości! Więc tak, całkowicie możliwe.
Podobno nowy jest w atm. [Źródło] (http://steamcommunity.com/groups/reddit#announcements/detail/145594019967735932)
Jako bonus, JPEG + ZIP jest również techniką steganografii - jedna ignoruje dodatkową zawartość na końcu pliku, a druga na początku pliku.[Przykład.] (Https://github.com/MiroslavVitkov/scripts/tree/master/crypto)
Pięć odpowiedzi:
gowenfawr
2015-08-27 00:10:55 UTC
view on stackexchange narkive permalink

Czy istnieje coś takiego?

Oczywiście. Dostarczanie złośliwych danych wejściowych do parsera jest jednym z najczęstszych sposobów tworzenia exploita (aw przypadku plików JPEG „dekompresja” jest „analizowaniem”).

Czy ten opis jest oparty na jakimś rzeczywistym exploit?

Może opierać się na przepełnieniu bufora Microsoft Windows GDI +:

Istnieje luka przepełnienia bufora w sposób, w jaki składnik analizujący JPEG GDI + (Gdiplus.dll) obsługuje zniekształcone obrazy JPEG . Wprowadzając specjalnie spreparowany plik JPEG do zagrożonego komponentu, osoba atakująca zdalnie może wywołać stan przepełnienia bufora.

...

Zdalny, nieuwierzytelniony osoba atakująca może potencjalnie wykonać dowolny kod w systemie zawierającym lukę, wprowadzając specjalnie spreparowany plik JPEG. Ten złośliwy obraz JPEG może zostać wprowadzony do systemu poprzez złośliwą stronę internetową, wiadomość e-mail w formacie HTML lub załącznik wiadomości e-mail.

.

Zostało to opublikowane w grudniu 2006 roku.

Luka w zabezpieczeniach analizująca GDI + JPEG została opublikowana we wrześniu 2004 roku.

Czy rozsądnie jest powiedzieć, że „system operacyjny” dekompresował obraz, aby go wyrenderować?

Jasne; w tym przypadku była to biblioteka systemowa, która wymagała poprawki producenta systemu operacyjnego, aby ją poprawić. Często takie biblioteki są używane przez wiele pakietów oprogramowania, co sprawia, że ​​są częścią systemu operacyjnego, a nie aplikacji.

W rzeczywistości „aplikacja pocztowa wywołała bibliotekę systemową w celu przeanalizowania pliku JPEG”, ale „ system operacyjny ”jest wystarczająco blisko, aby zapisać powieść.

Jeśli dobrze pamiętam, niektóre z początkowych metod „łamania więzienia” dla konsoli Sony Playstation Portable (PSP) wykorzystywały „specjalnie spreparowany” plik obrazu, który zepsuł dekoder PSP i umożliwiał wykonanie kodu osadzonego w pliku JPG.
„osoba atakująca mogłaby potencjalnie wykonać dowolny kod” czy to szablon dla * dowolnego * błędu przepełnienia bufora? Podniesienie uprawnień z wątku trybu użytkownika byłoby kolejnym problemem.
@JDługosz, tak, to standardowy opis. Większość CVE i opisów luk w zabezpieczeniach używa zestawu standardowych fraz, takich jak „[lokalny | zdalny] atakujący mógłby potencjalnie wykonać [dowolne] [polecenia | kod] [z uprawnieniami [użytkownik | podwyższony poziom]]”. Ponowne użycie zwięzłych słów kluczowych i wyrażeń („schematyczne”) umożliwia obrońcom szybką ocenę ryzyka - na przykład słowo kluczowe [local | remote] jest ważne w ocenie ryzyka. Frazy użyte w komunikacie GDI + mówią mi, że kod działa z uprawnieniami użytkownika otwierającego JPEG - w 2004-2006 Windows, często Administrator!
Ten exploit byłby możliwy tylko wtedy, gdyby omawiany algorytm dekompresji zawierał błąd, który umożliwiał wykonanie dowolnego kodu, prawda?
@TripeHound tak, kolory tęczy, zdjęcie na okładce powłoki ducha i format tiff do użycia chickHEN. Nadal mam te gdzieś tutaj. Edycja: tak, kurczak, ale nie tiff: /
@JDługosz Używają terminu „atakujący mógłby potencjalnie wykonać dowolny kod” zamiast „przepełnienia bufora”, ponieważ efekt jest ważniejszy dla celów podejmowania decyzji niż faktyczne użycie metody. Na przykład nie obchodzi mnie, czy przepełnienie bufora, aby wstrzyknąć kod, czy też jailbreak, otwierając nowy proces, który odbiera i wydaje polecenie. Ważnym efektem jest to, że osoba atakująca może teraz wydawać kody bajtowe na moim komputerze.
@MaxNanasy Tak - ale tak jest * zawsze *; czasami jest to błąd w kodzie, czasami jest to błąd w systemie operacyjnym, czasami jest to błąd w projekcie. Jak pokazało wiele przykładów, wiele parserów * robi * w rzeczywistości ma te błędy - myślę, że przepełnienie bufora prowadzące do wykonywania kodu jest najczęściej obserwowanym. To jeden z powodów, dla których MS wypchnęło platformę .NET - tak długo, jak długo pozostajesz bezpiecznie w zarządzanym środowisku, po prostu wyeliminowałeś jedną ogromną ścieżkę luk w zabezpieczeniach. Oczywiście wiele parserów będzie używać niebezpiecznego kodu ze względu na wydajność, więc nie jest tak dobry, jak mógłby być, ale nadal pomaga.
Nic Barker
2015-08-27 08:18:34 UTC
view on stackexchange narkive permalink

Zgadzając się z innymi, że tak, jest to całkowicie możliwe, ale dodam też ciekawą anegdotę:

Joshua Drake (@jduck) odkrył błąd oparty na bardzo podobnej koncepcji (obrazy są interpretowane przez system operacyjny), który został nazwany „Stagefright” i wpłynął na absurdalną liczbę urządzeń z Androidem.

Odkrył również podobny błąd oparty na obrazie w libpng który spowodowałby awarię niektórych urządzeń. Napisał na Twitterze przykład exploita, mówiąc: „Hej, sprawdź ten fajny złośliwy plik PNG, który stworzyłem, prawdopodobnie spowoduje awarię twojego urządzenia”, nie zdając sobie sprawy, że Twitter dodał automatyczne renderowanie obrazów w treści. Nie trzeba dodawać, że wielu jego obserwatorów zaczęło zawieszać swoje maszyny w momencie, gdy przeglądarka próbowała załadować miniaturę obrazu do ich kanału.

W rzeczywistości struktura multimediów nazywa się „Stagefright”, ale nazwa jest na tyle chwytliwa, że ​​można ją nazwać „błędem Stagefright”. /poza tematem
user158037
2015-08-27 20:48:15 UTC
view on stackexchange narkive permalink

Nierealne? Niedawno wystąpił krytyczny błąd podczas analizowania definicji czcionek: https://technet.microsoft.com/en-us/library/security/ms15-078.aspx, a libjpeg changenotes zawiera wiele porad dotyczących bezpieczeństwa. Przetwarzanie plików [1] jest trudne: przepełnienia, niedomiar, dostęp poza granicami. Ostatnio opracowano wiele narzędzi do półautomatycznego wykrywania danych wejściowych, które mogą powodować awarie.

[1] lub pakietów sieciowych, zapytań XML, a nawet SQL.

Tak ... bardzo trudne z niezarządzanym kodem --.- Gdyby kodować tylko w kodzie zarządzanym, przepełnienie / niedomiar bufora zmniejszyłoby się do poniżej 1% ich obecnego wpływu na bezpieczeństwo ...
Gdyby twórcy kompilatora C byli zainteresowani promowaniem niezawodności, C mógłby przewyższać Javę w wielu zadaniach, w których semantyka brzmi: „Biorąc poprawne dane wejściowe, generuj poprawne dane wyjściowe; mając nieprawidłowe dane wejściowe, generuj luźno ograniczone dane wyjściowe”. Niestety, wydaje się, że autorzy kompilatorów nie są tym zainteresowani i wolą zoptymalizować logikę, która zapobiegałaby krytycznym dla bezpieczeństwa formom UB, jeśli nie zapobiegałaby występowaniu w tych samych formach UB, które w innym przypadku byłyby nie-krytyczne dla bezpieczeństwa. sytuacje.
Kod zarządzany @Falco: nie jest darmowy; z drugiej strony, ponieważ hipernowoczesne C eliminuje wiele zalet wydajnościowych C, które posiadał w przypadkach, gdy programiści nie dbali o dokładne zachowanie w przypadkach takich jak przepełnienie, jedynym sposobem, w jaki widzę, że C pozostaje konkurencyjny, jest oficjalnie skataloguj zachowania, które nie były gwarantowane przez Standard, ale były szeroko wdrażane, i pozwalają programistom na ich określenie.
@Falco Niestety, zarządzane środowiska wykonawcze również mają swój udział w przepełnieniach bufora. Ludzie, którzy napisali Javę, wykonali okropną robotę, używając programowania obronnego do ochrony słabych punktów środowiska wykonawczego. W rzeczywistości właśnie natknąłem się na jeden w najnowszej Javie (i zgłosiłem go Oracle, który to potwierdził). Wszystko sprowadza się do nierozważnego dążenia do przedwczesnej optymalizacji. Zastanawiam się, czy nagle mamy przełom i uda nam się zbudować chipy 20 GHz, czy programiści w końcu przyjdą na granice i tym podobne. A może są zbyt uparci.
MS15-078 jest jeszcze bardziej niepokojący, ponieważ sterownik czcionek Adobe * działa w trybie jądra *.
@AleksandrDubinsky Nie wstrzymywałbym oddechu - mieliśmy kilka wzrostów rzędu wielkości szybkości przetwarzania, a tak wielu wciąż trzyma się unikania sprawdzania granic. Powody, które mieli do tej pory, będą nadal takie same, jeśli procesory będą działać 1000x szybciej. Jest jednak nadzieja - na przykład firma Microsoft Research od podstaw pracowała nad w pełni rozwiniętym, zarządzanym systemem operacyjnym - nie został on zaprojektowany pod kątem wydajności, ale raczej bezpieczeństwa i ochrony, ale dla projektu badawczego nadal działał wystarczająco dobrze. A kiedy cały system operacyjny jest zarządzany, unikasz kosztów komunikacji między zarządzanymi i niezarządzanymi.
Emilio M Bumachar
2015-08-31 00:42:25 UTC
view on stackexchange narkive permalink

Jak zauważyli inni, takie ataki zwykle wykorzystują przepełnienie bufora.

Jeśli chodzi o najciekawsze sposoby, nazywa się to atakiem niszczącym stos. Polega ona na uszkodzeniu stosu wywołań i nadpisaniu adresu do prawidłowego kodu, który ma być wykonany, adresem do kodu dostarczonego przez atakującego, który jest zamiast tego wykonywany.

Szczegółowe informacje można znaleźć pod adresem insecure.org/stf/smashstack.html.

TheJulyPlot
2015-08-27 00:08:04 UTC
view on stackexchange narkive permalink

Tak, jest to możliwe:

Nowy wariant nikczemnego trojana bankowego Zeus - nazwany ZeusVM - jest ukryty w plikach obrazów JPG, zgodnie z ustaleniami Jerome Segury, starszego badacza bezpieczeństwa z Malwarebytes i francuskim badaczem bezpieczeństwa Xylitolem.

Czyn ten jest znany jako steganografia - ukrywanie wiadomości lub obrazów w innych wiadomościach lub obrazach.

W przypadku ZeusVM kod złośliwego oprogramowania to ukryty w skromnych obrazach JPG, ujawnił poniedziałkowy post na blogu Segury. Te zdjęcia służą jako wskazówka dla ZeusVM w celu pobrania pliku konfiguracyjnego.

„JPG zawiera plik konfiguracyjny szkodliwego oprogramowania, który jest w istocie listą skryptów i instytucji finansowych - ale nie musi być otwierany przez same ofiary ”- powiedział Segura SCMagazine.com we wtorkowej korespondencji e-mailowej. „W rzeczywistości sam plik JPG jest bardzo mało widoczny dla użytkownika i jest w dużej mierze techniką maskowania, która zapewnia, że ​​nie zostanie wykryty z punktu widzenia oprogramowania zabezpieczającego”.

Źródło.

Chociaż technika * jest * możliwa w przypadku wadliwego dekodera JPEG, nie wydaje się, aby był to przykład. Jest to po prostu zakodowanie pliku konfiguracyjnego w formacie JPEG w celu ukrycia aktualizacji * istniejącej * infekcji. Wydaje się, że OP pyta o obrazy JPEG jako wektor do przenoszenia nowych infekcji.
Cóż, jeśli chcesz być pedantem, parsowanie i dekompresja to dwie odrębne rzeczy, nawet w jpegach i szerszej informatyce. Jeden opisuje dane * w pewnym sensie *, drugi, cóż, coś dekompresuje. Tak czy inaczej, złośliwe oprogramowanie może być dostarczane za pośrednictwem plików jpeg przy użyciu wielu dyskretnych metod.
Myślę, że ten przykład jest nawet bardziej interesujący niż zwykły zainfekowany obraz, z którym użytkownik prawdopodobnie będzie musiał wejść z nim w interakcję. Ten przykład przedstawia raczej wyrafinowaną złośliwą metodę, która nie przyciąga uwagi użytkownika i może prowadzić do ataków typu man-in-the-browser
Celem zainfekowanego obrazu wykorzystującego dekompresor JPEG jest to, że * nie * wymagana jest interakcja. Jeśli masz wadliwą implementację JPEG, jak w przykładzie GDI + dostarczonym przez @gowenfawr,, możesz zostać naruszony, po prostu przeglądając stronę internetową lub wiadomość e-mail. Takie obrazy mogą być wyświetlane przez skrypt reklamowy nawet na zaufanych witrynach. Jest to * o wiele * bardziej interesujące i niepokojące niż używanie JPEG jako pozornie nieszkodliwego mechanizmu komunikacji dla * istniejącej * infekcji.
Rozumiem, o co ci chodzi, ale nie ma to związku z moim komentarzem. Możesz zostać zainfekowany, po prostu pobierając obraz w przeglądarce przez to również. Przykład gowenfawrs był dobrym przykładem tak, zgadzam się. Bliżej teoretycznego przykładu z pierwotnego pytania. W każdym razie, jak powiedziałem, istnieje wiele różnych metod dostarczania złośliwego oprogramowania przez jpeg, w tym ten, który przedstawiłem jedynie jako przykład złośliwego oprogramowania w formacie jpeg. https://blog.malwarebytes.org/security-threat/2014/02/hiding-in-plain-sight-a-story-about-a-sneaky-banking-trojan/
@TheJulyPlot Myślę, że nie rozumiesz, jak to działa. W tym przykładzie trojan Zeus wykorzystuje plik jpg do ukrycia sposobu, w jaki pobiera swój plik konfiguracyjny. Komputer już zainfekowany trojanem pobierze obraz i wyodrębni dane. Obraz zawiera tylko (ukryty) plik konfiguracyjny, a nie trojana i nie ma własnego mechanizmu infekowania systemów. Nie możesz zostać zainfekowany, po prostu pobierając obraz w przeglądarce.
Wcale nie mylę się… tak naprawdę to zostało opisane w linku, który zamieściłem.
Nie jestem pewien, czy „wyrafinowany” naprawdę opisuje coś takiego. Dekodery JPEG generalnie działają po prostu na bajcie EOF (jeśli jest obecny), co jest tak proste, jak konkatenacja dowolnego innego pliku na końcu pliku obrazu. Potrzebne jest tylko `cat img.jpg evil.zip> evil.jpg`.


ⓘ
To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...