Újabb súlyos sebezhetőség linuxokon

Linux-security

HUP cikket is megérne, de nem vagyok annyira kreatív: https://www.bleepingcomputer.com/news/security/linux-system-service-bug…

  • 1713 megtekintés

( Raynes v | 2022. 01. 27., cs – 04:31 )

Írtam róla tegnap a miért használsz Linuxot szavazás alatt. A legtöbb disztró 1 napon belül foltozta ezt a sebezhetőséget a polkit 0.120-as verzióval. Plusz ez inkább desktopokat érint, hiszen GUI-khoz van szánva, így szervereken nem szokás polkitet használni. Nagy teendő nincs, frissíteni kell mindenkinek, aki nem kapná meg az új verziót, annak azt ajánlják, hogy chmod 0755 /usr/bin/polkit parancsot adjon ki. A média megint túllihegi, azt hiszik, hogy most megfogták az isten lábát ezzel a nagy szenzációval.

Ez inkább csak lusta meg ókonzervatív desktop userekre veszélyes, akik még szándékosan nem támogatott disztrót használnak, és nem kapnak már rá frissítést.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ez inkább csak lusta meg ókonzervatív desktop userekre veszélyes, akik még szándékosan nem támogatott disztrót használnak, és nem kapnak már rá frissítést.

Nem, rájuk nem veszélyes, mert ők általában nem adnak hozzá más lokális usereket, akik SSH-zgatnak a gépükre és local root exploitokat futtatgatnak.

Ez már egy legalább két lépcsős támadási vektor és kell hozzá egy sebezhető böngésző, meg egy eléggé egységsugarú tapicskoló, aki rámegy az oldalra.

Az ilyen oldalakat például számos uBlock Origin listán is szűrik, ami a mai internetes állapotokat nézve gyakorlatilag kötelező extension.

Decemberben láttam egy-két Facebook ismerősnél Soros Györgyös kamuoldalt, amit megnéztem közelebbről és egy imgur-ra feltöltött JPEG-be ágyazott payload-dal támadt. Már amikor hozzám eljutott, le volt szűrve a uBlock malware listák által és nem is engedte volna megnyitni, ha rákattintok se.

Ha ésszel használja az ember a gépét és ésszel internetezik, tetszőleges legacy rendszeren lehet biztonságosan böngészni. Biztonságosabban, mint a tapicskolók netezgetnek Windows 10-11-en.

Böngésző nem kell hogy sebezhető legyen, csak egy internetről elérhető apache + mod_php és egy szokásos lyukas PHP kódhalmaz a szervereden.
A többletet egy a téma általi sebezhetőség abban hozza, hogy nem csak www-data user nevében fog tudni végrehajtani és hozzáférni korlátozottan mappákhoz, hanem eljut az exploittal a root-ig és innentől kezdve bármit megcsinál (ír, olvas, futtat, átkonfigurál) a szervereddel.

Nem is kell hozzáadni, elég ha van root, márpedig az a legtöbb disztrón van. SSH is telepítve van, meg ne kérdezd minek, gondolom csak bekészítették, hátha valakinek kell, és kezdőknek ne kelljen vergődni, ha nem tudják hogy kell telepíteni, engedélyezni. A másik, hogy ehhez az exploithoz ártó kódot kell futtatni, de a disztrók hivatalos tárolóiba nem kerül be ilyen, így ha valaki megbízható forrásból telepít, desktopon se lesz érintve. Én egyébként ezt az egész polkitet utálom, de nem tudtam a rendszerből kiirtani, a systemd, dbus mindenképp behozza függőségnek a polkitd-t sajnos, és ott fut egy plusz sz@r a háttérben, ami úgyse kell, meg csak biztonsági probléma, minimalista WM-en senki nem használja. SSH az nálam nincs, mivel nem kell desktopra, az headless eszközökön meg szervereken hasznos. Ha annyira emelet szintű GUI alkalmazást akarnék (nem kellett már nagyon régóta), akkor root-ként is tudok komplett WM-et futtatni, ha meg csak konzolban, terminálban kell egy CLI/TUI apphoz (99%-ban csak ilyeneket használok), ahhoz meg elég a sudo, su, doas, tty-ban rootként bejelentkezés, néha esetleg sudoedit vagy doasedit is megteszi, ha csak valami fájlt kell szerkeszteni, és ehhez a text editornak nem kell emelt szintű jogosultságokkal futnia. Ez a szép a Linuxban, hogy mindent meg lehet oldani 1001-féle módon, elegánsabb és minimalistább megoldások is vannak, és nem csak az az út létezik, amit az öltönyös-nyekkendős multimanagerek megálmodtak a meetingeken.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Hagyd. Nem fogja megérteni.

Ő is a fejlődésmániások rosszabbik fajtája, akik minden elméletben lehetséges, összetett támadási vektort ugyanakkora valószínűségűnek éreznek, mint a legegyszerűbbeket. Ezért az egyetlen megoldást a folyamatos frissítgetésben látják. Még akkor is, ha közben használhatatlanul bloat-tá válik alattuk a rendszer és már csak command line tool-okkal tudnak boldogulni.

"Ezért az egyetlen megoldást a folyamatos frissítgetésben látják." - te persze szerencsés vagy, mert az XP-bőrbe varrt w2k3-at nem kell frissítgetni...

"használhatatlanul bloat-tá válik alattuk a rendszer" - 14.04-es Ubuntu lett 20.04-re felhúzva szépen sorjában, naprakészre frissítve. Nem lett bloat,  a verziócserék okozta javítanivalókat kikalapálva minden működik.

"már csak command line tool-okkal tudnak boldogulni" - Mondja ezt az XP-s felületen nevelkedett, és ott is ragadt, csak egerészéssel boldogulni képes hájblézer...

az XP-bőrbe varrt w2k3-at nem kell frissítgetni...

Semmit sem kell. Senki nem kényszerít rá.

verziócserék okozta javítanivalókat kikalapálva

:D

Mondja ezt az XP-s felületen nevelkedett, és ott is ragadt, csak egerészéssel boldogulni képes hájblézer...

Boldogulok én a command line toolokkal is, de nem akarok, ha van náluk hatékonyabb.

A saját józan eszem arra kényszerít, hogy józanul, ésszel és biztonságtudatosan használjam a nem frissített rendszerem, mintsem rákattintsak minden szar hülyeségre, és hátradőlve kényelmeskedjek, mert a frissítések úgyis megvédenek™ (ami számos esetben kiderült már, hogy nem igaz).

Ha kell klikkelned ugye, mert ha a png, html, xml, vagy jpg libben van a bug, akkor elég ha a beágyazott (és behekkelt) kép megjelenik a kedvenc webáruházad vagy sima weboldalad kódjában és helo. Ahány Joomla, Drupal vagy Wordpress van megnyomva, csoda, hoyg ez nem mindennapos. A frissítés sosem jelentett 100%-os biztonságot, meg láttunk már olyat, hogy konkrétan elb...tak funkciót (lásd a régi Debian vs. ssh vs. kulcsgenerálást), de sajnos nem kerülhető meg. Itt is van ez a pkexec jellegű történet.

Hát nem tudom. Én csak arra voltam kíváncsi, hogy nálam épp fenn vannak-é ezek a dolgok. A polkit biztos frissült pár hete.

Az, hogy Rynes fejlődés mániás? Az csak a saját ökoszisztémájára igaz, szerintem. Önmagához képest fejlődik, abba az irányba, amit jónak lát a maga számára. A puritánabbnál puritánabb rendszereit, mindig a maga igényeihez alakítja. Viszont megértem a Te érveidet is a saját igényeidet figyelembe véve. Néha azért túl toljátok.
Jó magam nem szeretnék egy évek óta "end of life" rendszert foltozgatni. Viszont a puritánság jegyében sem szeretnék magamnak plusz órákat eltölteni, bármelyik pálcika WM konfigurálásával. Valahol kettőtök közt egy napra kész disztró egy kellemes DE-vel kielégíti minden vágyam.  

Jól van, hagyunk, nem tudsz olvasni. Nem azt írtam, hogy mindegyik disztrón van, hanem hogy a legtöbbön van. Akkor ezek szerint Elementary-n nincs, nem bizonyít semmit, mert nem állítottam, hogy van.

A lényeg lényege, hogy ez a polkit szinte csak GUI alatt használt, akkor is nagyon ritkán. Elméletileg lehetne GUI nélkül is használni, de ebben a szerepkörben meg senki nem használja, mikor ott a su, sudo, doas, tty admin login. Szerverekre meg végképp nem telepítik, mert nem szükséges, és csak egyel több dolog, ami eltörhet, vagy támadási felület, sechole forrás lehet, és lám, pont ez képezi most a hírt, hogy bizony sechole van benne.

A másik meg, hogy a legtöbb desktop disztrón, ahol polkit használva van, ott már nagy részt javították kb. 24 órán belül, Debian, Ubuntu, RHEL, Arch ágakon mindenképp, vagy a 0.120-as verzióval, vagy egy régebbi verzióba visszaportolással. Így lényegében ez a sérülékenység csak nagyon kevés rendszert érint, ott is a saját lustaságának lesz az áldozata, aki ezt beszívja (nem frissít, vagy nem tud frissíteni támogatás lejártával).

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Most az a baj, hogy épp írtam egy olyan példát, amin épp nincs? A "van root" meg az én értelmezésemben azt jelenti, hogy su parancsra kapsz-e root shell-t vagy nem? Vagy extrém esetben root felhasználóval még GIU-ra is be tudsz jelentkezni. Arch-on su-ra biztos kapsz root shell-t, de egy Ubuntu-n vagy sudo-s Debian-on biztos nem. Az én értelmezésemben ezeken a rendszereken, ha nem tudják "kompromittálni" a user "sudo" jelszavát, akkor hogyan szerznek "root" jogot?

Függetlenül attól, hogy a fent általad is említett "polkit" sebezhetőség mindehová megérkezett javítva.

Debian minimal netistall telepítőben is opcionális az SSH és a Webserver telepítő is pl. .

"az én értelmezésemben ezeken a rendszereken, ha nem tudják "kompromittálni" a user "sudo" jelszavát, akkor hogyan szerznek "root" jogot?" - https://en.wikipedia.org/wiki/Privilege_escalation

Volt 20+ éve egy AIX tanfolyam, ahol elvileg rendszergazdai képzést kaptunk, de a tanfolyami gépre csak sima usert kaptunk, úgyhogy sokmindent nem tudtunk vele kezdeni - egészen addig, amíg egy adott OS-verzión létező, foltozatlan local root exploit nem jött szembe az egyik kollégával, aki - az oktató tudtával - lefordította a nyúlfarknyi programot, és máris volt root shell.

Nem, nem baj, hogy írtad, hajbi kötött bele, neki írtam. Ha ilyen tágan értelmezzük egyébként, ahogy te írod, akkor ilyen értelmezésben minden disztrón van „root”, hiszen valamilyen módszerrel, su-val, vagy sudo shellnév paranccsal biztosan tudsz valamilyen módon emelt jogosultságot szerezni, még ha az adott felhasznjálót nem is root-nak hívják. Egy „disztró”-t tudok, ahol ez nem lehetséges, az igen kiváló észak-koreai Red Star OS. A minimal netinstall sehol nem tesz fel extrákat, attól minimal, nem csak a Debian, de az Ubunu minimal se, viszont azt kell érteni, hogy a desktop Linux felhasználók 99%-a nem Archot meg egyéb minimal installos disztrót használ, hanem valami full extrás, full DE, full bloatos mainstream Gnome/KDE/stb. desktopot, amiben tuti lesz polkit.

Ez a polkit mindenütt sebezhető volt, ahol fent volt, de javították. Kár, hogy a glibc-vel nem ilyen rózsás a helyzet. Súlyos sebezhetőség van a 2.33-as glibc-ben, amit az Arch már 5. hónapja nem javít, olyan indokkal, hogy a 2.34-es is sérülékeny (Fedorán elérhető), igaz az csak „low” besorolást kapott. Mai napig nincs sehol tökéletesen javítva, ami nem kicsit gáz.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ha már megdőlt volna, vagy a jövőben megdőlne bármitől a csodajó frissítetlen kövület elavult Windows rendszered, akkor azt bevallanád-e itt mindenki előtt, aki eddig olvasta a "nem kell a frissítés meg a korral haladás, én annyira tudok figyelni, hogy semmi baj nem lehet" írásaidat?

Szerintem a világ egyik legnagyobb hülyesége azt mondani, hogy nem kell naprakészen tartani bármilyen számítógép rendszert, és nem kell lecserélni a támogatásból/frissítésbőkl kifutott szoftvereket.

El sem tudom képzelni, hogy ha üzemeltetnél bárkinek IT dolgokat, és bármilyen biztonsági incidense lenne (és itt ugye nem kell rendszer feltörés vagy zsarolóvírus, elég csak egy titkosítás nélkül kiküldött e-mail, amiben olyasmi van, aminek nem szabadna benne lennie), amit jelentenie kell a megfelelő hatóságnak (törvényi előírás a kötelezettség), akkor a kivizsgálás során hogyan védenéd meg az elavult szoftvereket (ez ugye a tulajdonos/üzemeltető nem tett meg minden tőle telhetőt az incidens elkerülésére)? Vagy ügyfélnél naprakész vagy, csak otthon és itt a fórumon ragaszkodsz a muzeális cucchoz?

Hát nézd. Koca linuxosként erre nem tudok mit mondani. Ennyire mély részletességében nem szoktam a rendszert túrni. De ha elmondod, hogy ezt hogyan tudom ellenőrizni, akkor hálás leszek.
Gondolom ez a kérdés arra irányúlt, hogy szerintem nincs root a rendszeremen. Amit su, su -, su -i parancsok beírásával próbáltam ellenőrizni. Egyikre sem kaptam root promptot. Hitelesítési hiba és érvénytelen kapcsoló kimenet után kaptam vissza a user promptomat.

Ha ezen a szinten mozgunk, akkor a "nincs root" kijelentes lehet, hogy nem teljesen megalapozott?

Az egyszeruseg kedveert legyen mondjuk:

ls -l /

ls -ln /

Erosen meglepo lenne, ha nem lenne egy root user (a neve mindegy) a rendszereden. Ha sikerult elerned, hogy minden (de az osszes) rendszerfunkcionak kulon tulajdonosa (es hozzarendelt felhasznaloja) van, akkor tobb profi ceg is kilincselhetne nalad...

Szerintem a sudo és a systemd sem készült volna el, ha az alkotójuk látott volna AIX-et. Már az ezredforduló előtt tudott olyan dolgokat, amit most már a linux is tud, csak néhol rosszabbul.

Akkoriban még ssh sem volt, ezért FTP-n érkezett a titkosított adatbázis. Méghozzá olyan módon, hogy a küldőnek sem írás, sem olvasási joga nem volt  a saját munkaterületére. Így aztán amit küldött, azt sem tudta visszaolvasni. (Tehát a küldő jelszavát megszerezve sem lehet ellopni a küldeményt.) Természetesen a rendszer más területeihez sem tudott hozzáférni, kivétel a /tmp. Annak a védelmét az összes ftpuser ellen (szintén) ACL védte.

Igen, némi tervezéssel tetszőleges *NIX rendszeren ki lehet alakítani teljesen jól működő, de faék egyszerűségű védelmet, csak ahhoz már gondolkozni és tervezni kell. Manapság meg születik egy új protokoll a fokozott védelem miatt, majd egy utility, amivel át lehet nyúlni a védelem felett. Minden egyre kaotikusabb és néha lukasabb is lesz.

A sudo helyett ott az ACL. Amikor fejlesztettünk is és üzemeltettünk is, de nem root-ként, más jogokat is adtunk magunknak.* Pl. a man mount alapján a az alkalmazás "tecnical user-e" megkapta azt a jogot, amivel a mount végrehajtható lett. A linux a root:root 755 + setuid-dal el is intézi, tehát "hagyományosabb" a jogosultági rendszer kialakítása.

Annak idején egy VMS specialista átnézte a teljes AIX jogosultsági rendszert, és megfelelőnek találta. Ez azért nagy szó, mert a VMS kifejezetten banki rendszerekhez is jó volt.

Azóta az AIX is fejlődött egy kicsit: Role-based access control. Itt megint látszik, hogy ez nem linux, mert meg van tervezve. ;)

*A régebbi, AIX 6.1 előtti megoldásokról a fenti linken turkálva olvashatsz. Amiről feljebb írtam, azt AIX 3.2 - AIX 5.3 környékén alkalmaztuk.

( uid_6201 v | 2022. 01. 27., cs – 08:31 )

Lefutott, ott a root prompt.
# apt upgrade
És már nem futott le.

ii  policykit-1                          0.105-31+deb11u1
már nem engedi.

( hajbazer v | 2022. 01. 27., cs – 09:37 )

Szerkesztve: 2022. 01. 27., cs – 09:46

A polkitd egyike azon Red Hat szemeteknek, amiket telepítéskor leszedünk a gépről.

A Red Hat a multik által értelmezett biztonságot™ hozta el a Linux világba. Azt, amit a Microsoft a Windows Defenderrel, aminek a sebezhetőségein keresztül válik támadhatóvá a rendszer.

Lehet ezt még fokozni.

Volt már olyan, amikor megkértem az auditort, hogy jegyzőkönyvezzen. Ugyanis olyan csomagokat kellett felrakni a  nagyértékű auditáló szoftver futtatásához, ami a szerveren biztonsági megfontolásból nem volt. A mai fejemmel megtagadtam volna a szoftver futtatását - jegyzőkönvezze azt!

A Windowson egészen rémisztő dolgok folynak. Soha nem tudhatod mi fut, még a rigorózus beállítások ellenére sem. A linux meg már utol is érte. ;)

Ott a pont. Szerintem az lehet erre a megoldás,  hogy a konténerizált motyó szállítója a felelős a konténerben lévő komponensek biztonsági frissítéséért, és neki kell a konténerből új verziót adnia. Mint amikor egy statikusan fordított binárisban egy beledrótozott lib lukas, akkor sem a futtatókörnyezet, hanem a bináris szállítója a felelős. De ide sorolhatom például a log4j sebezhetőséget is: a war-ba bele van csomagolva a sérülékeny - az alkalmazás szállítója adjon új war-t, amiben a sérülékeny komponenst lecserélte.

"biztonsági szempontból nem jobb, sőt"... ezt ugye nem olvastad el még egyszer? nem arról van szó, hogy "konténerben fut, hát leszarhatom".

pl. egy ilyen polkites lópikulából nem lesz igazi root, nem fog tudni onnan kitörni, stb. (unprivileged konténerről beszélek, of course és nem a netről össze-vissza tákolt dockerről, hanem lxc-ben debian pl.)

én két dolog miatt szoktam konténerbe rakni a dolgaimat: 1. security (ha valaki fel is nyomja azt a szoftvert, azért a szerver többi részéhez nem fér hozzá) 2. mindenféle csomag felrakása nem fogja szétnyomni a host rendszert. 3. könnyen át tudom vinni egy másik gépre

"konténerben fut, hát leszarhatom".

 

pedig én pontosan ezt látom a gyakorlatban.

 

Akit valóban érdekel a biztonság az természetesen  tudja jól csinálni.... De ők tudtak ezt konténerek nélkül is ;)

csak korábban még nem volt ilyen kényelmes, így neked kellett hozzá kernelt hegeszteni, meg 'chroot jail' összepakolni, stb.

zrubi.hu

Pár hónapja az egyik ügyfelünk megbízott egy külső auditort a weboldala "biztonsági ellenörzésére", eredménye:

- sikerült ddos-olni a szervert 65 féle módszerrel, ami nagyon nem jó és óriási biztonsági kockázat.

A gyakorlat így nézet ki:

- az auditor a munka elkezdését követően 5 másodperc alatt fennakadt a tűzfalon, majd a fél órás timeout után ismét visszavarázsolta magát másodpercek alatt. Kikönyörögte magának a whitelist -et, így már sikeresen lenyomta a ddos-t, majd beleírta az elemzésbe :>

// Happy debugging, suckers
#define true (rand() > 10)

Kikönyörögte magának a whitelist -et, így már sikeresen lenyomta a ddos-t, majd beleírta az elemzésbe 

^^ mondjuk ezt is nevezhetjük sikeres ddosnak és beírhatja simán auditba ... Itt azért meg kellene vizsgálni, hogy ki, hol, miért és mikor rakta ezeket whitelist-re. Ha azzal rakták őket whitelistre, hogy mi vagyunk a nagy audit cég és whitelist kell, akkor nem kerülhetne bele a "jelentésbe". Viszont, ha nem ezzel hanem körbekamuztak mindent is hogy nigériai herceg, stb. és whtelist -> akkor jogos hogy berkerült a "jelentésbe".

de fixme

A mi ügyfelünk jelezte a számunkra, hogy bár nem így tervezték, mert szerették volna a tudtunk nélkül elvégezni az audit remote részét, anélkül, hogy mi elkezdenénk "előtte rendetrakni", de az audit cég csúnyán megakadt így a folyamatban és "nem tudják befejezni". Elsőre nemet mondtunk, hogy elvégre erről szól az audit, de a "távoli kódinjectálást" is szeretnék ellenőrizni mindenütt, ami így nem fog menni ha fennakadnak lépten nyomon.

Szóval már itt is egy kis ferdítéssel kapták meg, ügyfelen keresztül (szóval nem random a semmire kapták :) )

// Happy debugging, suckers
#define true (rand() > 10)

( p2pking | 2022. 01. 27., cs – 16:18 )

Ez nudli.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.