Simone Margaritelli, forfatteren af firewall OpenSnitch og netværksanalysatoren bettercap, afslørede for tidligt information om tidligere annoncerede kritiske sårbarheder, der tillader fjernangreb på GNU/Linux, Solaris, FreeBSD og nogle andre BSD-systemer. Oprindeligt var offentliggørelsen planlagt til den 6. oktober, men på grund af lækage af information måtte oplysningerne offentliggøres tidligere, før de fleste distributioner kunne nå at forberede opdateringer. Sårbarhederne berører CUPS printserveren og tillader eksekvering af kode i systemet uden autentifikation.
Forskeren, der identificerede problemet, har forberedt en fungerende prototype af et exploit, der bruger en kombination af flere sårbarheder og giver mulighed for fjerneksekvering af kode med rettighederne for CUPS printjob-processen (normalt brugeren "lp"). Exploitet gør det muligt diskret at ændre printerindstillingerne for brugeren eller tilføje en ny printer, der er forbundet til en angribers kørende IPP-server, som leverer en specielt formateret PPD-beskrivelse af printeren. Behandling af denne PPD under start af printjobbet fører til udførelse af angriberens kode (det er nødvendigt, at offeret initierer printen på den manipulerede eller erstatte printer).
Systemer med serveren CUPS printserver og en kørende cups-browsed proces, der accepterer netværksforbindelser på port 631 (UDP) er sårbare. Angrebet kan også udføres fra det lokale netværk, hvor protokoller som zeroconf, mDNS eller DNS-SD anvendes til at få adgang til server print. Kun konfigureringer af cups-browsed, hvor parameteren BrowseRemoteProtocols i filen /etc/cups/cups-browsed.conf er sat til "cups", er sårbare. I distributioner med systemd kan brugen af cups-browsed tjekkes med kommandoen "sudo systemctl status cups-browsed".
Sårbarheden optræder i alle CUPS-baserede printsystemer, der bruger sårbare versioner af pakkerne cups-filters, libcupsfilters, libppd og cups-browsed. Rettelser er i øjeblikket kun tilgængelige som patches (1, 2, 3) — de aktuelle versioner af cups-filters 2.0.1, libcupsfilters 2.1b1, libppd 2.1b1 og cups-browsed 2.0.1 er sårbare. I distributionerne forbliver problemet uløst; opdateringer kan følges på følgende sider: Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, FreeBSD. Som en midlertidig beskyttelsesforanstaltning indtil installationen af opdateringen, kan adgangen til UDP-port 631 fra eksterne netværk blokeres, service cups-browsed deaktiveres eller indstillingen BrowseRemoteProtocols sættes til 'none'.
Identificerede sårbarheder:
- CVE-2024-47176 — en sårbarhed i processen cups-browsed, der opretter en netværkssocket, der accepterer forbindelser på port 631, tilknyttet til alle eksisterende netværksinterfaces i systemet, og accepterer IPP-forespørgsler 'Get-Printer-Attributes' fra enhver ekstern system. Gennem manipulation med denne service kan en printer, kontrolleret af angriberen, tilføjes til systemet og udnyttes ved at overføre PPD-konfigurationer af sårbarheder i andre CUPS-komponenter.
- CVE-2024-47177 — en sårbarhed i foomatic-rip-behandleren fra pakken cups-filters, der muliggør udførelse af kode ved at overføre parameteren FoomaticRIPCommandLine i PPD-filen, som angriberen kan sende takket være den ovenfor nævnte sårbarhed i cups-browsed. De shell-kommandoer, der angives i parameteren FoomaticRIPCommandLine, udføres som de er, uanset at parameteren kan indstilles af en uvedkommende. For eksempel kan man angive 'FoomaticRIPCommandLine: echo 1 > /tmp/VULNERABLE' for at skrive til filen /tmp/VULNERABLE.
- CVE-2024-47175 — en sårbarhed i libppd, forårsaget af manglende validering af værdien ppdCreatePPDFromIPP2 ved skrivning af IPP-attriutter til en midlertidig PPD-fil. Problemet muliggør indsættelse af vilkårlige data i den resulterende PPD-fil ved at vedhæfte attributter, der bruger linjeskifttegn. For eksempel kan man omgå valideringen og indsætte FoomaticRIPCommandLine-attributten sammen med tilladte attributter for at udnytte den ovennævnte sårbarhed i cups-filters.
- CVE-2024-47076 — en sårbarhed i libcupsfilters-biblioteket fra cups-filters-pakken, der er relateret til mangel på validering af værdierne cfGetPrinterAttributes5, der returneres af en ekstern IPP-server. Dette giver en angriber mulighed for at få behandling af vilkårlige IPP-attributter i andre CUPS-subsystemer, for eksempel ved generation af PPD-filer.
Angrebsvejen til CUPS kan opsummeres i følgende trin:
- Udrulning af en angrebsvens egen IPP-server.
- Sending af en UDP-pakke til offeret med et link til den printer, der er knyttet til den kørende IPP-server fra angriberen.
- Efter modtagelsen af denne pakke opretter offerets system forbindelse til angriberens IPP-server og anmoder om printerens attributter.
- Som svar på offerets anmodning returnerer angriberens IPP-server en PPD-fil med attributter, hvoriblandt attributten FoomaticRIPCommandLine angives. Denne attribut knyttes til en af de accepterede attributter ved at bruge symbolet "\n" i én linje (for eksempel "cupsPrivacyURI: "https://www.google.com/\n*FoomaticRIPCommandLine: "), hvilket muliggør omgåelse af valideringen og medfører, at FoomaticRIPCommandLine gemmes som en separat attribut, når dataene gemmes i en midlertidig fil.
- Som følge af behandlingen af de overførte attributter i offerets system oprettes der en PPD-fil: … *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 -" …
- Ved udskrivning til den manipulerede printer på offerets system vil kommandoen "echo 1 > /tmp/I_AM_VULNERABLE" blive udført.
Forskeren, der opdagede sårbarhederne, bemærker, at det tog ham et par dage at finde sårbarheden, men derefter fulgte en langvarig korrespondance, der varede 22 dage, med udviklerne af OpenPrinting-projektet i et forsøg på at overbevise dem om vigtigheden af problemet og nødvendigheden af at forberede patches. Diskussionen blev fastlåst i stridigheder om, hvorvidt de nævnte problemer overhovedet skulle rettes, og situationen blev først vendt ved at skabe offentlig opmærksomhed omkring opdagelsen af dette kritiske problem. Det er også interessant, at der opstod en lækage, hvor den fortrolige rapport og udnyttelsen, der blev sendt til CERT, dukkede op på breachforums.st-forummet i offentligt tilgængelighed, på trods af et embargo mod offentliggørelse af oplysninger.
Kilde: opennet.ru
