PixelSmash, czyli podatność, która może zaatakować zewsząd

Jeśli mamy potencjalnie ciekawą medialnie i rozległą w swoim zasięgu podatność, nie może zabraknąć efektownej nazwy, która na długo zapisze się w słowniku wszystkich zainteresowanych cyberbezpieczeństwem. W przeszłości były to ShellShock, Heartbleed, Spectre, Meltdown, Log4Shell, Dirty COW i wiele innych. Hasło na dziś to PixelSmash. Nie mam pewności, czy PixelSmash w social mediach i serwisach traktujących o cyberbezpieczeństwie zrobi taką karierę, jak te wymienione przed chwilą, jednak niezależnie od tego, warto przyjrzeć się temu problemowi. A jest on potencjalnie szeroki, bo też szerokie jest zastosowanie samej biblioteki FFmpeg. Zagrożenia związane z eksploitacją systemu po otwarciu pliku kojarzymy głównie z plikami wykonywalnymi. Znaleziona przez JFrog podatność w bibliotece FFmpeg jest dobrym powodem do tego, aby zrewidować ten popularny pogląd. Pakiet FFmpeg jest szeroko używany w systemach na komputerach biurkowych, w urządzeniach IoT, serwerach NAS, platformach do udostępniania plików i wielu usługach chmurowych. To wszystko sprawia, że możliwy negatywny wpływ podatności sięga daleko poza grono osób świadomie wykorzystujących bibliotekę podczas dekodowania multimediów czy też zwyczajnie odtwarzających wideo w odtwarzaczu.

TLDR:

• Poważna podatność wykryta w FFmpeg. Powszechność zastosowań pakietu sprawia, że skutki potencjalnego ataku mogą nadejść z kierunków, które tradycyjnie uważamy za bezpieczne. W wielu przypadkach eksploitacja jest możliwa nawet w sytuacji, kiedy świadomie nie otwieramy złośliwego pliku.
• Badaczom z JFrog udało się przeprowadzić skuteczne ataki DoS, a w określonych warunkach także doprowadzić do zdalnego wykonania kodu w systemie ofiary. Mnogość wektorów ataku, a także bardzo ospałe podejście do łatania luki przez dostawców systemów operacyjnych są dobrym powodem, aby przyjrzeć się bliżej temu problemowi.

Luka oznaczona identyfikatorem CVE-2026-8461 otrzymała wysoką ocenę 8.8 w CVSS 3.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). To błąd typu out-of-bounds write w dekoderze MagicYUV. MagicYUV to bezstratny kodek wideo przeznaczony do wysokowydajnych procesów edycji wideo. Jest częścią biblioteki zawierającej dekodery libavcodec dla setek kodeków wideo i audio. Teoretycznie jest szansa, że Wasz system zawierający FFmpeg nie jest podatny, bo choć MagicYUV nie jest tak popularny, jak H.264 czy VP9, to jednak dekoder ten występuje we wszystkich typowych kompilacjach (domyślne parametry kompilacji FFmpeg zakładają obecność MagicYUV). JFrog podaje prosty sposób na sprawdzenie, czy nasza kompilacja jest podatna. Wystarczy wydać polecenie ffmpeg -decoders 2>/dev/null | grep magicyuv. VFS..D magicyuv w wyniku będzie oznaczało, że nasza kompilacja jest podatna na ataki. Dekoder MagicYUV może zostać uruchomiony przez dowolną aplikację obsługującą otwieranie plików wideo bez względu na to, czy będzie to kontener AVI, MKV czy MOV. Skuteczne wykorzystanie PixelSmash może skutkować atakiem DoS, a w określonych sytuacjach także zdalnym wykonaniem kodu w systemie ofiary.

Warto pochylić się nad tym, kto może stać się ofiarą ataku wykorzystującego ten problem bezpieczeństwa. Spektrum potencjalnych wektorów ataków jest tak szerokie, jak szerokie jest samo zastosowanie pakietu FFmpeg. Najbardziej oczywisty scenariusz eksploitacji zakłada przetworzenie pliku zawierającego odpowiednio spreparowane dane przez dowolną aplikację korzystającą z FFmpeg. Niestety, oznacza to, że w praktyce do skutecznej eksploitacji wystarczyć może już np. samo uruchomienie podglądu w miniaturce. W takiej sytuacji generator miniatur menadżera plików uruchomi złośliwy plik, a co za tym idzie, doprowadzi do wykonania złośliwego kodu. Pakiet FFmpeg można spotkać także w serwerach multimedialnych takich, jak Jellyfin, Emby, Nextcloud, Immich; komunikatorach takich, jak Slack, Discord czy Telegram. Usługi transkodowania w chmurze takie, jak AWS MediaConvert czy Cloudflare Stream również korzystają z FFmpeg, a w związku z tym są potencjalnie zagrożone skutkami wykorzystania tej podatności. Jak zwracają uwagę badacze z JFrog, w przypadku wspomnianych usług, serwery automatycznie przetwarzają przesyłane do nich materiały. Ponadto FFmpeg występuje także we wszelkiej maści urządzeniach IoT oraz systemach typu embedded takich, jak serwery NAS (Synology, QNAP), telewizory smart TV i wszelkie inne urządzenia multimedialne oferujące podgląd wideo lub przetwarzające multimedia.

Tak zespół JFrog Security Research opisuje działanie dekodera MagicYUV:

In video compression, a slice is a distinct, horizontally divided region of a single video frame that can be decoded independently from the rest of the frame.

Digital video rarely stores images in standard RGB (Red, Green, Blue). Instead, it uses the YUV color space, which splits an image into separate layers or “planes”:

    Y (Luma Plane): The brightness or grayscale details of the image. The human eye is incredibly sharp at detecting brightness.

    U & V (Chroma Planes): The actual color information. The human eye is much worse at seeing fine color details.

Dekoder dzieli obraz na mniejsze fragmenty (slices), które są następnie przetwarzane niezależnie od siebie. Wielkość każdego z nich określa parametr slice_height zapisany w strumieniu wideo. Obraz przechowywany jest w postaci oddzielnych składowych obrazu (planes). Osobno dla składowej jasności (Y) oraz składowych koloru (U i V). W formatach z podpróbkowaniem chrominancji takich, jak YUV420P, składowe U i V mają o połowę mniejszą rozdzielczość w pionie niż składowa Y. To sprawia, że dekoder musi odpowiednio przeliczać ich wysokość. Problem ujawnia się szczególnie wtedy, gdy wartość slice_height jest nieparzysta. Źródłem całego zamieszania jest rozbieżność między sposobem, w jaki FFMpeg wylicza wysokość składowych chrominancji podczas alokacji pamięci, a tym, jak to robi w trakcie dekodowania. JFrog opisuje ten problem jako rounding mismatch. Nieparzysta wartość slice_height doprowadza do sytuacji, w której dekoder stosuje zaokrąglenie w górę i dla każdego fragmentu dopisuje jeden dodatkowy wiersz danych. W efekcie dekoder zapisuje więcej danych niż przewidziano podczas alokacji, co z czasem prowadzi do błędu typu heap out-of-bounds write i uszkodzenia pamięci procesu.

Każdy kolejny fragment (slice) powoduje niewielki zapis poza bufor, który z czasem się kumuluje, co prowadzi do stopniowego nadpisywania kolejnych bajtów poza przydzielonym buforem na stercie (heap overflow). Badacze z zespołu JFrog Security Research przeprowadzili udaną próbę wykorzystania luki w serwerze multimediów Jellyfin za pośrednictwem modułu dostarczającego funkcję podglądu wideo oraz instancji Nextcloud, również z użyciem modułu generowania podglądów wideo. W obydwu przypadkach do wykorzystania podatności wystarczył specjalnie przygotowany plik AVI o rozmiarze 50 KB. Doświadczenia badaczy wykazują, że w najlepszym razie wykorzystanie luki zakończy się awarią procesu, jednak w sytuacji, kiedy atakujący przygotuje odpowiednio strukturę pliku i przewidzi sposób rozmieszczenia obiektów w pamięci, możliwe staje się nadpisanie wskaźników lub innych struktur sterujących przepływem wykonania programu. W swojej analizie badacze z JFrog dowodzą, że scenariusz, w którym wykorzystanie podatności prowadzi do zdalnego wykonania kodu (RCE) jest możliwy, choć w tym miejscu trzeba wyraźnie zaznaczyć, że ich demonstracja została przeprowadzona przy wyłączonym mechanizmie ASLR, który utrudnia przewidywanie adresów w pamięci, czyniąc potencjalne stworzenie uniwersalnego eksploita zadaniem co najmniej nietrywialnym. Działające ASLR nie powinno jednak przeszkadzać w przeprowadzeniu skutecznego ataku DoS.

Luka została naprawiona w wersjach 8.1.2 i 8.0.3. Naturalnie w przypadku oprogramowania pochodzącego z repozytorium naszego systemu operacyjnego, powinniśmy sprawdzić biuletyn bezpieczeństwa wydawany przez dostawcę naszego systemu. Specyfika samego oprogramowania dotkniętego tą podatnością oraz fakt, że jej potencjalne wykonanie może nadejść z kierunku, którego się nie spodziewamy, powinna po raz kolejny skłonić nas do dokładnego przyjrzenia się naszym politykom bezpieczeństwa. Złożony łańcuch dostaw, z jakim stykamy się na co dzień powoduje, że zagrożenie może nadejść nawet ze strony oprogramowania, które uważamy za zaufane. Ten przypadek pokazuje, jak ważna jest skuteczna i przemyślana izolacja procesów oraz zasobów we współczesnych systemach operacyjnych. Nawiasem mówiąc, mimo że informacja o podatności została opublikowana już jakiś czas temu, opiekunowie popularnych dystrybucji Linuksa w dalszym ciągu ociągają się z wydaniem stosownych poprawek. Tym bardziej nie mamy też większych nadziei, co do wielu rozwiązań IoT i embedded.

Źródło: JFrog Security Research

~pu