Vlákno názorů k článku
Zranitelnost v CUPS umožňuje vzdálené spuštění kódu od Vít Šesták - Možná něco nechápu, ale přijde mi to trochu...

Možná něco nechápu, ale přijde mi to trochu zmatené:

1. Útočník musí inzerovat službu – nestačí, když se oběť třeba připojí nezabezpečeně k tiskárně, a útočník v síti to spojení unese k sobě? Potom by cups-browsed asi nepomohlo. Ale možná je tu nějaké specifikum, třeba potřeba nějaké specifické konfigurace tiskárny.
2. Může to být na veřejném internetu – jak se to z veřejného Internetu dostane až ke koncovému uživateli? Hádám, že půjde o nějaký autokonfigurační protokol, který bude určen jen pro lokální síť.
3. „Podle služby Shodan je takto z internetu dostupných minimálně 75 000 instancí tiskového démona CUPS.“ – předchozí popis zněl jako útok na klienta, toto jsou servery, ne? Nebo řešíme scénář, kdy chybí dostatečná autentizace a útočník si sám nakonfiguruje zákeřnou tiskárnu a pošle do ní job?

1) Pokud to chapu dobre, tak ta vopicarna (cups-browsed) si odchytava tiskarny ktere se hlasi na tema "halo tady ja, tiskarna". Unaset spojeni je pak zbytecna prace navic.

2) kdyz ma nekdo tuhle vec pustenou do netu, tak proste na tu adresu dorucis prislusne pakety s prislusnym ohlasenim tiskarny, a ono to ty pakety proste prijme a zpracuje

3) viz vejs, tohle ti bezi typicky na klientovi, ale je to servisa = klient je v pozici serveru. Sshd je taky vec ktera ti muze bezet i na klientovi ale je to servisa. Na serveru tohle naopak typicky mit nebudes protoze nechces aby ti nejak sam pridaval tiskarny.

Tuhle to mas popsany https://github.com/OpenPrinting/cups-browsed

Aby ta zranitelnost fungovala, musím mít veřejnou IP, jinak to z venku nepůjde heknout?

Musel bys mit:
- verejnou IP
- povolenej port 631 z internetu na tve pc/nb
- na pc/nb mit nainstalovanou A spustenou sluzbu cups-browsed (ktera v siti vyhledava automaticky sitove tiskarny, nestaci mit je zakladni cups sluzbu pro tisk)
- a mozna jeste neco ;⁠-⁠)

Takze to zneuziti je doma (a kdekoliv kde nejake pako nenastavi tisk k sobe z internetu) v podstate "nerealne", neco jineho by bylo kdyby utocnik byl v tve lokalni siti, pak staci jen abys mel aktivni tu sluzbu cups-browsed

To už nejspíš zlehčujete. IIUC, cups-browsed hledá v lokální síti. Stačí, když útočník bude zde.

Veřejná IP apod. by nejspíš umožnila při slabém/žádném hesle provést ten útok i bez cups-browsed.

cups-browsed je od toho, aby skenovalo dostupné tiskárny v síti a ty nabízelo k nastavení a využití. Povaha toho útoku je, že se můžete vydávat za tiskárnu, kterou chce uživatel použít a během toho můžete v systému vzdáleně pouštět kód. Je to tedy útok na klienta, ne na server poskytující tiskárnu.

Zní to blbě, ale je tam mnoho podmínek, které se musí splnit. Zaprvé cups-browsed není prakticky na žádné serverové distribuci ani předinstalovaný, na desktopových je, ale by default nebývá aktivovaný. Útočník musí mít přístup do lokální sítě. V systému musí být otevřený firewall. Je tam vyžadována interakce uživatele, který musí tu podvrženou tiskárnu použít. No a jestli jsem to dobře pochopil, tak i když se útočníkovi podaří vzdáleně kód pustit, běží to pod uživatelem lp a SELinux dopad prakticky kompletně eliminuje.

Jako člověku, který to nahlásil, patří dík za to, že to na blogu velmi pěkně popsal a dal si práci to řešit s vývojáři, ale přijde mi trochu jako drama queen, protože před zveřejněním to vypadalo, že pomalu skončí svět, hromada pláče nad tím, že vývojáři na tak zásadní zranitelnost nereagovali dostatečně rychle... a ve výsledku z toho je celkem běžné CVE.

Díky za upřesnění. Když projdu svoje otázky:

1. Stále nevím, jestli když útočník unese spojení s legitimní tiskárnou (nebo náležitě upraví SW tiskárny), jestli náhodou nemůže udělat útok tak jako tak, navzdory zakázanému cups-browsed.
2. Takže to jsem asi pochopil správně.
3. No právě, vystavený server sám o sobě IMHO nic neznamená…

1. jestli to jde udělat, netuším. Ukázkové exploity k tomuto případu pracují s vytvořením nové falešné tiskárny, která se musí na klientu přidat a použít.

To je zajímavé jak to někteří bagatelizujou, ale pořád se jedná o to, že někdo kontaktuje nějakou mašinu a předá ji payload, a pak ta mašina sama kontaktuje "útočníka" a ten ji předá co má "spustit"? Možná je to velké haló pro nic, ale upřímně ten cups je v tak špatném stavu, že se nedivím autorovi, že už na linuxu nikdy nic tisknout nechce.

Jako díval se někdo na ten cups-browsed kód? Vždyť tam je chyb jak máku a i toho by se přece dalo zneužít. A podezřelé je, že nad tím fuzzing nikdo nedělá a přitom je to služba co poslouchá a neumí ani bezpečně zpracovat vstupní data...

Myslím, že to nikdo nebagatelizuje, ale zrovna ten přístup, kdy někdo tvrdí, že na základě tohoto už na Linuxu nikdy nic tisknout nechce, tomu opravdu nepomáhá. CUPS a jeho síťové protokoly jsou tu skoro 30 let. Samozřejmě, že za tu dobu jejich návrh zastaral a nabalilo se na to mnoho obezliček, ale s tím holt musíme pracovat. Kompatibilita v tomto případě vyhrává. Nevyhodí se miliony tiskáren, abychom mohli tisknout bezpečně.

Proto se dělá CUPS 3.0, kde se mají ty PPD věci izolovat do samostatného procesu, který nebude nikam moct. A do té doby se bude omezovat, co to v systému může udělat. cups-browsed je plný blech, ale taky kde je dnes by default povolený? Ve Fedora Server nebo RHELu není ani předinstalovaný, ve Fedora Workstation je, ale není aktivovaný. I když by se všechny podmínky splnily a útočník byl schopný na vašem počítači spusti svůj kód, bude ho pouštět pod neprivilegovaným uživatelem lp, který se nikam pořádně nedostane. Může vám tak akorát vytisknout všechny papíry ze zásobníku.

Ve výsledku mají ta CVE hodnocení "important". To není dobré brát na lehkou váhu, autorovi patří dík za to, kolik si s tím dal práce, a opravit to, ale dělat z toho drama opravdu není potřeba. Jen náš tým řeší desítky CVE s ratingem "important" každý rok a je to "business as usual".

pak ta mašina sama kontaktuje "útočníka"

Sama nekontaktuje. Uživatel tu tiskárnu musí vybrat a tisknout na ní.

Toto je a ale v rozporu s tím článkem, kde se jasně píše:

HOLY SH!!!!! Not only it connected back immediately, but it also reported the exact kernel version and architecture in the User-Agent header! We’ll see later how this protocol also reports the requesting username (on the target) for some requests. Also this aspect, that to me matches pretty well with CWE-200, has been reported and just scoffed off as part of the mechanism. Alright … let’s not waste time on arguing whether or not this is a problem, let’s get to the juicy stuff. We know that this thing talks HTTP and POSTs some semi binary payload, what the hell is that?