Zdalne luki w serwerze druku CUPS

Simone Margaritelli, autor zapory OpenSnitch i analizatora sieciowego bettercap, przedwcześnie ujawnił informacje o wcześniej ogłoszonych krytycznych podatnościach, które umożliwiają zdalne ataki na dystrybucje GNU/Linux, Solaris, FreeBSD i niektóre inne systemy BSD. Publikacja pierwotnie miała być zaplanowana na 6 października, ale z powodu wycieku informacji musiała zostać opublikowana wcześniej, zanim większość dystrybucji zdąży przygotować aktualizację pakietów. Podatności dotyczą serwera druku CUPS i umożliwiają zdalne wykonanie kodu w systemie bez przechodzenia przez proces uwierzytelniania.

Badania przeprowadzone przez badacza, który zidentyfikował problem, doprowadziły do stworzenia roboczego prototypu exploita, który wykorzystuje kombinację kilku luk, umożliwiając zdalne wykonanie kodu z uprawnieniami procesu obsługi zadań drukowania CUPS (zwykle jest to użytkownik „lp”). Exploit pozwala na dyskretne zamienienie parametrów drukarki użytkownika lub dodanie nowej drukarki połączonej z uruchomionym serwerem IPP atakującego, który dostarcza specjalnie przygotowany opis drukarki PPD. Przetwarzanie tego PPD podczas uruchamiania zadania drukowania prowadzi do wykonania kodu atakującego (ofiara musi zainicjować drukowanie na podstawionej lub zamienionej drukarce).

Podatne na atak są systemy z serwerem drukiem CUPS i uruchomionym procesem cups-browsed, który akceptuje połączenia sieciowe na porcie 631 (UDP). Atak można również przeprowadzić z lokalnej sieci, w której do dostępu do serwera Podczas drukowania używane są protokoły zeroconf, mDNS lub DNS-SD. Wrażliwe są tylko konfiguracje cups-browsed, w których w pliku /etc/cups/cups-browsed.conf w parametrze BrowseRemoteProtocols ustawiono wartość „cups”. W dystrybucjach z systemd można sprawdzić użycie usługi cups-browsed za pomocą polecenia „sudo systemctl status cups-browsed”.

Luka występuje w wszystkich systemach drukowania opartych na CUPS, w których używane są wrażliwe wersje pakietów cups-filters, libcupsfilters, libppd i cups-browsed. Poprawki są obecnie dostępne tylko w postaci łat (1, 2, 3) — aktualne wersje cups-filters 2.0.1, libcupsfilters 2.1b1, libppd 2.1b1 i cups-browsed 2.0.1 są podatne na luki. W dystrybucjach problem pozostaje nierozwiązany, a aktualizacje można śledzić na następujących stronach: Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, FreeBSD. Jako tymczasowy sposób ochrony przed zainstalowaniem aktualizacji można zablokować dostęp do portu UDP 631 z zewnętrznych sieci, wyłączyć usługę cups-browsed lub ustawić parametr BrowseRemoteProtocols na wartość „none”.

Zidentyfikowane luki:

• CVE-2024-47176 — luka w procesie cups-browsed, który tworzy gniazdo sieciowe, przyjmujące połączenia na porcie 631, przypięte do wszystkich dostępnych w systemie interfejsów sieciowych i przyjmujące żądania IPP „Get-Printer-Attributes” z dowolnych zewnętrznych systemów. Poprzez manipulację tą usługą można osiągnąć dodanie do systemu drukarki kontrolowanej przez atakującego, a następnie wykorzystać ją poprzez przesłanie konfiguracji PPD, co zagraża innym komponentom CUPS.
• CVE-2024-47177 — podatność w obsłudze foomatic-rip z zestawu cups-filters, umożliwiająca wykonanie kodu poprzez przekazanie parametru FoomaticRIPCommandLine w pliku PPD, który atakujący może przesłać dzięki wcześniej opisanej podatności w cups-browsed. Komendy shell wymienione w parametrze FoomaticRIPCommandLine są wykonywane dosłownie, bez uwzględnienia tego, że parametr może być ustawiony przez osobę postronną. Na przykład, aby zapisać do pliku /tmp/VULNERABLE, można podać „FoomaticRIPCommandLine: „echo 1 > /tmp/VULNERABLE”.
• CVE-2024-47175 — podatność w libppd spowodowana brakiem weryfikacji poprawności wartości ppdCreatePPDFromIPP2 podczas zapisu atrybutów IPP do tymczasowego pliku PPD. Problem pozwala na podstawienie dowolnych danych do wynikowego pliku PPD poprzez dołączenie atrybutów, używając znaku nowej linii. Na przykład, można obejść weryfikację i razem z dozwolonymi atrybutami dołączyć atrybut FoomaticRIPCommandLine w celu wykorzystania wcześniej wspomnianej podatności w cups-filters.
• CVE-2024-47076 — podatność w bibliotece libcupsfilters z pakietu cups-filters, związana z brakiem weryfikacji wartości cfGetPrinterAttributes5 zwracanych przez zewnętrzny serwer IPP, co daje atakującemu możliwość zorganizowania przetwarzania dowolnych atrybutów IPP w innych subsystemach CUPS, na przykład podczas generowania plików PPD.

Scenariusz ataku na CUPS sprowadza się do następujących kroków:

• Rozwój własnego serwera IPP przez atakującego.
• Wysłanie do ofiary pakietu UDP z odwołaniem do drukarki przypisanej do uruchomionego przez atakującego serwera IPP.
• Po otrzymaniu tego pakietu system ofiary łączy się z serwerem IPP atakującego i żąda atrybutów drukarki.
• W odpowiedzi na żądanie ofiary, serwer IPP atakującego zwraca plik PPD z atrybutami, wśród których znajduje się atrybut FoomaticRIPCommandLine. Atrybut ten jest dołączany do jednego z dozwolonych atrybutów, używając znaku „\n” w jednej linii (na przykład „cupsPrivacyURI: „https://www.google.com/\n*FoomaticRIPCommandLine: „), co pozwala na obejście weryfikacji i prowadzi do zapisu FoomaticRIPCommandLine jako osobnego atrybutu przy zapisywaniu otrzymanych danych w pliku tymczasowym.
• W wyniku przetwarzania przesłanych atrybutów w systemie ofiary tworzy się plik PPD: … *cupsSNMPSupplies: False *cupsLanguages: „en” *cupsPrivacyURI: „https://www.google.com/” *FoomaticRIPCommandLine: „echo 1 > /tmp/I_AM_VULNERABLE” *cupsFilter2 : „application/pdf application/vnd.cups-postscript 0 foomatic-rip” *cupsSingleFile: True *cupsFilter2: „application/vnd.cups-pdf application/pdf 0 -” …
• Podczas drukowania na podstawioną przez atakującego drukarkę w systemie ofiary zostanie wykonana komenda „echo 1 > /tmp/I_AM_VULNERABLE”

Badacz, który ujawnił luki, zauważa, że znalezienie luk zajęło mu kilka dni, ale następnie nastąpiła przedłużająca się o 22 dni korespondencja z deweloperami projektu OpenPrinting, mająca na celu przekonanie ich o ważności problemu i konieczności przygotowania poprawek. Dyskusja ugrzęzła w sporach, czy w ogóle warto naprawiać te problemy, a sytuację udało się przełamać jedynie poprzez wzbudzenie publicznego szumu wokół ujawnienia krytycznego problemu. Interesujące jest również pojawienie się wycieku informacji, podczas którego przekazany do CERT poufny raport i exploit pojawiły się na forum breachforums.st w otwartym dostępie, mimo wprowadzonego embarga na ujawnienie informacji.

Źródło: opennet.ru