Názory k článku
Kritická zranitelnost linuxových systémů dostala hodnocení CVSS 9.9, oprava zatím neexistuje

heh, tak podle toho jak nadava na arogantni vyvojare, to bude v systemd

To si nemyslim, to by neovlivnovalo vsechny distra.

Tak autor explicitně zmiňuje "všechny GNU/Linux systémy a některé další". Kdyby to bylo v systemd, tak by spíš napsal "většinu distribucí".
Takhle to spíš vypadá buď na chybu v jádře, nebo - můj tip: chyba někde v binutils nebo možná glibc nebo Bashi, když autor specificky píše "GNU/Linux" namísto "Linux". Tomu by ostatně i odpovídal ten dodatek "a některé další [systémy]"
Uvidíme.

linus sice starne, ale nerekl bych ze by drzkoval kdyby nekdo nasel RCE v jadru, takze jadro bych vyskrtl...

Nevím, ve zprávě se explicitně píše že jde o chybu kernelu a to RCE.
To spíš smrdí buď na nějaký děravý subsystém kolem sítě, který je v defaultu zapnutý.
Nějak si vzpomínám na ctcp nedávno. Uvidíme.

kde se pise o kernelu?

Nikde se nepíše o zranitelnosti jádra. Objevitel chyby píše o zranitelnosti linuxových systémů, specificky "GNU/Linux a některých dalších". Může být jádro, nemusí. Nevíme.

ve zprávě se explicitně píše že jde o chybu kernelu
Nevím, zda se zpráva neměnila, ale o kernelu se tam nic nepíše, naopak je tam napsáno, že se pravděpodobně týká i dalších platforem, ne jen Linuxu.

V téhle zprávičce se to tak původně psalo, ale zřejmě už to spravili.

Na otázku ohľadom FreeBSD mi odpovedali:

Buonasera,

non si sa ancora, ma è probabile.

Attendiamo entro la prossima settimana nuove notizie.

Grazie

Jelikoz jsem rozumnel jen Buonasera a Grazie, tak jsem to zkusil nechat prelozit DeepL:
"Good evening,
no word yet, but it is likely.
We are expecting within the next week new news.
Thank you"
Treba nekomu usetrim kopirovani do prekladace.

Četl jsem včera, celé je to podezřelé. V linkovaném článku je reklama na jakýsi bezpečnotní software Bettercap na kterém člověk pracuje. Nikde není ani památky (odkaz) o tom, že by Red Hat opravdu něco potvrdil, to je jen jakési tvrzení kohosi na twitteru. Pokud je to celé pravda, tak proč nezveřejní číslo CVE? To není tajná informace, bývá přiděleno ihned a dalo by to všemu nějakou váhu. S CVE se dá normálně pracovat veřejně i když je pod embargem, často firmy (včetně Red Hatu) dávájí o závažných chybách oznámení ve smyslu "Pracujeme na vážné opravě CVE-2024-12345, vyčkejte dalších instrukcí". Nic jsem nezaznamenal.

Pravdou je, že některé chyby opravdu mohou trvat velmi dlouhou dobu opravit. Ono to není jen tak backportovat větší patch to třiceti kernelů, otestovat to, zkomunikovat a synchronizovat.

Je to hodně divné. Není CVE, nejsou ani IPS signatury, které většina vendorů vydává v řádech několika hodin, zvláště pokud se jedná o remote vulnerability.

Ještě trvá embargo, takže nikdo konkrétní informace nebo dokonce opravy zveřejňovat nesmí.

Ale zveřejnění čísla CVE snad nic nebrání, ne? Zejména když má dneska CVE kdejaká blbost…

minimalne v dobe psani toho clanku 23.9. (odkaz "objevil a nahlásil") tam pise:
- Still no CVE assigned

No uvidime. Je mozne, ze to score je nadsadene (ostatne aj Simone napisal, ze hype je to, co pomaha dotlacit fix).

Na twitteri som cital, ze vraj sa to tyka aj Windows a BSD. Co fakt neviem, co za RCE by to mohlo byt. SSH ? To by com cakal, ze by sa opravilo rychlejsie.
Fakt som zvedavy.

To bude chyba v Intel CPU. Zase nějaká super security feature je děravá jako cedník.

Vsadím boty na nějakou Intel technologii.

Linux a další, RCE, dekádu přítomné, když jsem jen v rychlosti projel o čem ten člověk psal v minulosti, tak to tipuji třeba na něco okolo IPv6 a Extension headers nebo nějaké takové podobné šílenosti. To by i odpovídalo, že někde na začátku vznikla jedna implementace s "BSD licencí", co všichni ostatní jen vzali a moc se v tom nepřehrabovali.

26. 9. 2024, 20:41 editováno autorem komentáře

Jako že je děravý IPv6 stack?
Upravíš paket a payload se spustí...uh....
Mehehehe :-D to by byl průser jako sv....
Hlavně s dopadem na všechny dsl, wifi, telky, IoT, IPkamery .. :-D

Negativní:
Elektroměr by mi mohli hacknout :-(

Pozitivní:
Mohl bych si ho hacknout sám :-)

26. 9. 2024, 21:49 editováno autorem komentáře

Že by to už bylo venku?
https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/

Před 14 minutami na twitteru zveřejnil https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/

Tak pohoda, nic děsivýho. :)

26. 9. 2024, 22:15 editováno autorem komentáře

CUPS, tiskne asi skoro kazdej.

Hmmm, a já už se chystal trhat síťové kabely a omotat wifiny rolí alobalu.

Jo, z toho oznámení to vypadalo minimálně na možnost ovládat PC s linuxem podupáváním morzeovky ze sousedního patra...

Tak jsem rad ze mam opt-in distro bez bloatware a zminenou diru jsem nemel nikdy nainstalovanou .. tisknu proste z win virtualky :)

*  net-print/cups-browsed
      Latest version available: 2.0.1
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 417 kB
      Homepage:    https://github.com/OpenPrinting/cups-browsed
      Description: helper daemon to browse for remote CUPS queues and IPP network printers
      License:     Apache-2.0

ja nainstalovane mam, ale ze bych se desil CVSS 9.9 na sluzbe ktera funguje jen v lokalni siti a nema tam pristup ani guest Wifi, natoz z internetu? ;-)))

Uff, už jsem podle skóre trochu bál, že to bude fakt 0-click na něco, co běží úplně všude. Sice asi trochu divadla okolo, nedokážu posoudit nutnost, ale možná to bylo fakt oprávněné, aby se pohnuly ledy.
Sice to sám nikde naštěstí nepoužívám, ale nechci to úplně zlehčovat. Už to, že mu odpovídaly stovky tisíc zařízení na nějaký scan ze Shodanu je peklo. I když tohle si ale říkám v podstatě pokaždé - WTF?, kdo tyhle služby nechá poslouchat na veřejné adrese (a je jedno jestli se bavíme o síť. browseru na tiskárny nebo nějakém otevřeném administračním rozhraní od router, switche atp.), zvlášť pokud je to posledních 10-15 let všechno většinou opt-in a musí se to někde explicitně povolit, pronatovat u IPv4 atd.

Předesílám, že s CUPS mám minimum zkušeností, všude jsem to vždycky vypínal, nebo odinstaloval, když to opravdu nebylo třeba a nikdy to vlastně moc nezkoumal. Ale zarazilo mě, když jsem si to četl, co tam je z dnešního pohledu za hrůzy. Teď nemyslím ty samotné validace na úrovni paketů, IPP atd., i když to vypadá taky pěkně. Ale vůbec celý ten koncept, že tam jsou stovky ovladačů od legacy tiskáren, které prostě pro ripování můžou volat nějaký systémový příkaz s takhle vysokými právy. Plus se tam ještě dají dynamicky poslat úplně nové (neověřené) pomocí PPD z random tiskárny zvenku. To mi přijde jako velká potenciální díra.
Jako chápu, že na některé své činnosti CUPS potřebuje vyšší práva - jako otevření socketů s privilegovanými porty, posílání do určitých lokálních rozhraní, ale jestli takhle běží rovnou všechno.. bez privilege separation. To zní pekelně. Byť asi RH based distribuce s povolenými SELinux pravidly by na tom mohly být líp.

I když fixnou ty konkrétní CVE, tak je to podle mě k zamyšlení, co s tím dál. Minimálně všechny ty legacy tiskárny, co tohle potřebují, by-default vypnout. Důrazně varovat, že přidávaná IPP tiskárna používá PPD s foo-rip deklarací a vyžadovat explicitní povolení.. atd.

Souhlas,
ten FoomaticRIPCom­mandLine hack je silenej. Vzdy jsem si pochvaloval ze pripojit tiskarnu k linuxu je snazsi nez na Windows a ted poprve vidim na cem to drzi pohromade.

27. 9. 2024, 08:42 editováno autorem komentáře

CUPS je pod kapotou dost silenej. Viz "Can not print on Tuesday bug".

https://www.youtube.com/watch?v=-6fPfwixNLk

Pod kapotou se skryva divoka zmet scriptu, ktere se snazi "uhadnout" co a jak zpracovat.

Ono to je totiž dědictví divoké minulosti... Kdo si vzpomene, jak náročné bylo zprovoznit tisk 15 až 20 roků zpět? To se tisk obecně skládal z rovnáků no vohejbáky, aby to vůbec něco možná tisklo... Dneska je to už brnkačka o ničem, ale to dědictví si stále CUPS nese.

Asi by stálo za to zamyslet se nad situací a vytvořit CUPS-ng bez této historické zátěže. Sice by spousta majitelů historických tiskáren křičela, ale ti by mohli zůstat u současného CUPS.

To tedy je. Tuesday bug super!
Já chápu, že to v nějaké fázi bylo asi rychlejší takhle nahackovat, volat si externě file, perl.. Ale že nebyla nějaká tendence ty úkony, co tím dělají (nahrazování řetězců, identifikaci souborů atp.) třeba postupně u všech ovladačů převést na nějakou speciální interní knihovnu. Nebo budiž, pokud vyloženě potřebují interpretr, tak tam udělat třeba interní LUA skriptování, které bude mít přesně vydefinované omezení na to kam může přisupovat, kolik si vezme paměti atd.
Ale jestli tohle, stejně jako celý cupsd, běží pod právy roota, tak je to úplně šílené, přesně jak říkáte. (Tam ani nemusí být škodlivý kód, nebo podvržené PPD, stačí jedna blbá chyba v ošetření cyklu nebo změna chování externích utilit a může to třeba při RIPování nebo preprocessingu klidně zaplnit celý disk, partition)

Ale samozřejmě tady kecám od stolu, druhý největší problém po celé téhle "architektuře" bude v tom, že i kdyby to někdo zkoušel přepsat, tak nebude mít hardware, aby to ozkoušel.

Minimálně by podle mě měli vývojáři ty největší hrůzy identifikovat a udělat aspoň nějaké doporučení na "hardened" nastavení, případně to utáhnout a doplnit nějaké konfigurační direktivy. Chápu, že pro spousty lidí teď nebude řešením vypnout CUPS. A do budoucna to začít čistit a minimálně nějak dělit části, aby to běželo s různými oprávněními. Celé mi to tak trochu připomíná první monolitické mail servery, co si mohly volat různé ext. procesory, cca 20 let zpátky.

Uvidíme, co vyplave v druhém díle s Bonjour (dns-sd).

"kdo tyhle služby nechá poslouchat na veřejné adrese"

To mas easy. BFU si koupi krabku, nejak ji nekam zapoji kabely, a ono to nejak funguje. Proc by jako mel zkoumat proc a jak? Mno a typicka krabka ma proste vsude povoleno vsechno, protoze proc se pak s tim BFUckem dohadovat, ze si cosi koupil a ono mu to nefunguje, protoze nekde neco nezap.

Pus ti nmap a nech ho scanovat ... uvidis sam. Staci kdyz projedes svy okoli a uvidis veci ...

A uvidis to i u firem, sam se rozlidni po zdejsich diskusich, kde se henti "administratori" chodi ptat na uplny zaklady. Takze co bys od nich jako cekal?

jestli krabkou myslis router, tak jakej model ma povolenej port 631 z internetu a forwarduje ho na kazde PC/NB ktere k te krabce pripojis?

Právě, že tohle mi to nejde moc do hlavy.
Podobně jako u těch routerů.
Za posledních řekněme 15 let jsem viděl hodně routerů a modemů různých druhů. Od profi, přes střední kategorii, něco od operátorů, až po různé nejlevnější Tendy atp. Pokaždé byla ta web administrace ve výchozím stavu vypnutá z WAN sítě. Totéž packet filtr, stavový fw, zavřená všechna spojení navazovaná zvenku. Pokud si explicitně neuděláš port forward.
Dobře je tam ještě dynamické otevírání např. přes UPnP, nebo STUN, ale to jsou typicky specifické druhy aplikací, které to opravdu potřebují ke své funkci a je to aktivní, jen když ta aplikace běží.

Ale pak tu často narazím na nějaké zprávičky, kdy je CVE pro chybu routeru (nevím ASUS, DLink..) v jeho web. administraci a k tomu se pojí info, že jsou jich stovky tisíc on-line s veřejným přístupem po nějakém scanu. K tomu právě směřuje to WTF? To jsou nějaké hloupé návody, úplný laik se tam většinou ani nedokliká, aby tohle nastavil.
Podobně u tohohle problému s CUPSem, kdo si úmyslně pronatuje port 631 TCP/UDP na konkrétní IP dovnitř (ještě na stroj s Linuxem nebo řekněme OS X, kde běží cups-browser). To se nestane samo a nic tím nezískáš.
Jediné vysvětlení, co mě napadá, že to byly většinově IPv6 hosty (ve statistice nezveřejňuje). Viděl jsem ještě pár let zpátky výchozí packet filtry opravdu nastavené jen pro IPv4, takže cokoliv co IPv6 dostalo adresu přes PD, bylo rovnou dostupné z internetu. Například jedna řada ASUS modemů to neuměla nastavit vůbec (teda z GUI, ssh/telnetem to samozřejmě šlo ručně, ale jen do restartu). Ale i to už se výrazně zlepšilo u novějších zařízení, co jsem viděl.

Nezapomeňte na routery, které samy mají instalované cups - a pak opravdu stačí málo (třeba jedno kliknutí na Povolit administraci z WAN - protože nepochopíte, že WAN není WLAN ), a nesštěstí je hotovo.
Je pravda, že takovou věc jsem už pěkných pár let nepotkal, ale taky obvykle rychle vyměním firmware za OpenWRT nebo tak něco...

Tak reálně to skoré bude nižší, je potřeba celkem dlouhý řetězec kroků:

1.The cups-browsed service has manually been enabled or started
2.An attacker has access to a vulnerable server, which :
.........a. Allows unrestricted access, such as the public internet, or
.........b. Gains access to an internal network where local connections are trusted
3. Attacker advertises a malicious IPP server, thereby provisioning a malicious printer
4. A potential victim attempts to print from the malicious device
5. Attacker executes arbitrary code on victim’s machine

https://www.redhat.com/en/blog/red-hat-response-openprinting-cups-vulnerabilities

Nicméně jen podle https://www.shodan.io/ je takto aktuálně náchylných přes 75.000 mašin s volně přístupným cups-browsed service

27. 9. 2024, 08:08 editováno autorem komentáře

Tak ten kdo vystavuje tiskovou službu po internetu asi zaslouží aby si vytisknul instrukce, jak to správně nastavit. S tou odhalenou vulnerabilitou by to mohl udělat vlastně kdokoliv... :-)

Dnes mi v Ubuntu nějaké opravy CUPS přistály, předpokládám, že to bude ono...

dobre popsano zde: https://www.youtube.com/watch?v=lXljErWpcRQ

Dobrý večer všem

Jsem v tomto pořád ještě nováček, tak mi, prosím, jen osvětlete: kritická zranitelnost " znamená, že jsem. Dosud žil v chiméře, že Linux je se facto nezbořitelný?? Tedy pokud nejde o beta verze. Mám ho na všem možném a jsem. S ním denně.

Do celé problematiky se s velkým zájmem teprve dostávám.

Děkuji a pokud je můj dotaz absurdní, omluvte mě.

Linux v žádném případě není nezbořitelný ani nenapadnutelný. Stejně jako u ostatních systémů je potřeba pravidelně jej aktualizovat, neinstalovat tam nedůvěryhodný software a nekonfigurovat tam věci, kterým nerozumíte.

Nicméně zrovna tato zranitelnost není zdaleka tak závažná, jak byla objevitelem původně prezentována. Vizte vedlejší zprávičku Zranitelnost v CUPS umožňuje vzdálené spuštění kódu, která popisuje větší detaily této zranitelnosti.