Na, tessék, itt egy élő példa, miért szoktuk azt mondani, hogy Fedora alatt az Nvidia driver telepítése nem olyan egyszerű. Illetve az, hogy frissítés után is menjen.

De egyébként ennyi elég lenne, nem?
sudo dnf install akmod-nvidia xorg-x11-drv-nvidia-cuda

Olvasnivaló:

https://news.ycombinator.com/item?id=39868673

https://news.ycombinator.com/item?id=39868673

https://www.openwall.com/lists/oss-security/2024/03/29/4

Izgalmas történet, bár nem tudom, mennyi az igazság belőle. Úgy tűnik, hogy egy olyan karbantartó csempészett backdoort az xz-be, aki évek óta hozzájárul a feljesztéséhez.
Azt rebesgetik, talán valamelyik szervezet embere lehet a tettes (ki tudja?). Mindenesetre a Github accountja (és egy másik emberé is) fel lett függesztve.
A végcél valószínűleg az lehetett, hogy hátsó ajtót nyissanak az SSH-ban.

Nincs sebezhetetlen rendszer, mindegyik torheto. A cybersecurity nem is ad 100% lefedettseget, de a nem celzott tamadasokat kivedi. Ha meg egy szervezetet celzottan tamadnak, az el fog bukni.

https://www.coreinfinity.tech

Egyébként az elmúlt ~2 évben 750 commitja volt az xz projekthez a backdoort elhelyező jóembernek (név szerint Jia Tannak, aki valószínűleg Szingapúrban vagy annak közelében él), így lehet, hogy fognak még backdoort találni korábban kiadott verziókban is. Folyamatosan nézik át a régebbi kódokat, de ez elég nehéz munka, eltart egy darabig.

Még egy érdekesség, a Jia Tan által beküldött commitban van egy szándékos hiba. Ezt úgy idézte elő, hogy az egyik függvény (my_sandbox) elé berakott egy .-ot: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7
Ez megakadályozta a Landlock nevű sandboxing működésbe lépését, így az xz olyan erőforrásokhoz is hozzáférhetett a rendszeren, amikhez alapvetően nem szabadott volna.
Lasse Collin commitja javította a hibát.

Na még ennyit: a backdoort Andreas Freund - Microsoft dolgozó - vette észre, amikor egy friss xz csomaggal ellátott Debian Sides gépre be akart jelentkezni SSH-n keresztül. A bejelentkezés irreálisan nagy CPU terhelést okozott, és a Valgrind hibákat dobott, ezekből vette észre, hogy valami nem okés. Itt az e-mailje: [link]

"openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma."
valahogy mindig visszajutunk a kályhához...

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Nice!

-=- There's no place like /home -=-

Itt teljesen egyértelműen az sshd-n akartak biztonsági rést nyitni. Hogy most ezt az systemd és az xz-n keresztül teszik meg, vagy más úton-módon, az már részletkérdés.

Nagyon kifinomult supply chain attack.

https://www.coreinfinity.tech

Így van. A csávó nagyon értette a dolgát, itt nem arról van szó, hogy valami script kiddie belekontárkodott a kódba, hanem nagyon kifinomult és alaposan eltervezett módon csempészte be a hátsó kaput.

Nem mondom, hogy nincs igazság abban, amit mondasz. Az tény, hogy a systemd marha nagyra nőtt, és ott van már PID1-ben majdnem az egész Linux, és ez nem biztos, hogy jó így.

De ez itt nem a systemd hibája volt. Ha bele akarunk menni, megkérdezhetjük, hogy miért gondolták jó ötletnek azt, hogy az sshd dependáljon a systemd-re? Én nagyjából tudom (mert utánaolvastam), azért, mert a systemd által nyújtott sd_notify() fv-t használja arra, hogy értesítse a systemd-et arról, amikor elindult.
Nem lehetett-e volna megoldani valami jó kis POSIX cuccal, vagy UNIX socket domainnel?
De biztos meg lehetett volna, de szerintem teljesen jogos volt a maintainerek törekvése arra, hogy ha már úgyis systemd-es környezetben fog futni az sshd, akkor használjuk már ki a systemd szolgáltatásait (ezzel systemd függővé tenni az sshd-t), mert hogy ennek előnyei is vannak. Nyilván, ha nem lennének előnyei, nem használnánk.
Tehát itt volt egy döntés a Debian és néhány másik disztribúció részéről, aminek lettek következményei. De szerintem ebbe nem nagyon lehet belekötni.

Persze, jó a nyílt forráskód, én a kényesebb adataimat nem is bízom zárt forráskódú programokra.
De ez a történet nem ilyen egyszerű. Itt emberi hibák is bőven belejátszottak abba, hogy ez megtörténhetett. Az egyik ilyen az volt, hogy Lasse Collin volt az xz egyedüli fejlesztője, aki mellékállásban, hobbiként csinálta, és aki egyébként mentális gondokkal is küzdött. Ami mondjuk nem meglepő, ha azt vesszük, hogy az xz egy kurva fontos szoftver az egész open source közösségben, és nyilván egy ilyen fontos szoftver fejlesztőjeként nem kis nyomás van rajtad.
Lehet, hogy ez az egész nem történt volna meg, ha a nagy cégek (Red Hat, Suse, IBM, Intel, Canonical...) kicsit jobban odafigyelnek az xz projektre, és nem egyetlen emberre bízzák az egészet. Jó lenne, ha ezek a cégek prioritizálnák a dolgaikat, és nagyobb hangsúlyt fektetnének a fontos szoftverekre, ahelyett, hogy a libadwaitát reszelgetik, hogy bugyirózsaszín ablakkeret mellé babakéket is be lehessen állítani.
Itt azért nem érvényesült a manyeyeball, mert nem volt manyeyeball. A backdoor sem azért derült ki, mert valaki vizsgálgatta a forráskódot, hanem mert a bináris túl nagy CPU loadot generált.
És mondhatnám azt, hogy zárt forráskódú programba eleve nem tud bekommitolni senki sem backdoort. De teljesen mindegy, szerintem ez a mostani egy tipikusan olyan dolog, amit nem lehet kivédeni.

Az xz backdoorhoz még annyit, hogy valaki csinált egy idővonalat, ami összefoglalja Jia Tan "fantasztikus" munkásságát, illetve néhány más érdekességet is lehoz: https://boehs.org/node/everything-i-know-about-the-xz-backdoor

Ebből is látszik, hogy már 2021-ben próbált ő backdoort csempészni a libarchive kódjába, illetve később több kamufiókkal együtt próbáltak nyomást gyakorolni, hogy a patchjeik kerüljenek bele a kódba, azután pedig el akarták érni, hogy az xz projekt vegyen be új fejlesztőket, ami sikerült is, így került be Jia Tin a fejlesztésbe. Az egyik nyomásgyakorló, "Jigar Kumar" szomorúnak tartotta (akit se előtte, se azóta nem látott senki), hogy az xz projekt nem halad, mert a jelenlegi maintainer (Lasse Collin) elvesztette az érdeklődését a projekt iránt, vagy nem törődik többé a karbantartással.
Biztos, hogy szervezett akció volt ez az egész, nem kizárt, hogy valamelyik kormányzat áll mögötte.

Na még itt egy érdekes összefoglaló: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

Egeszen biztosra veheted, hogy ez nem egy maganyos tamado, vagy bunozoi csoport terve volt, hanem egy nation-state actore.

https://www.coreinfinity.tech

Nade varja, ok kozvetetten patchelik a Windows-t: a hiba kideritese utan elobb bevonjak Kinat, hogy kozos erovel vegyek ra a Microsoftot a javitasra

[ Szerkesztve ]

https://www.coreinfinity.tech

Én egészen biztosra veszem

Az is elgondolkodtató, hogy hány ilyen szabotőr lehet még a nyílt forráskódú fejlesztők között.

Nekem a masik veg jutott eszembe: hany ilyen software lehet meg?

https://www.coreinfinity.tech

Akkor a nyilt forrásu szoftver mégsem olyan jó találmány?

Hulyesegek beszelese elott tajekozodjal.

https://www.coreinfinity.tech

De, nagyon jó találmány. De minden ellen nem véd.

Menj fel a PC Fórumra, majd ott Sting megmagyarázza neked, hogy mennyire nem biztonságos a nyílt forráskód

nincs 3 életem, így is csomó hülyét kerülgetek.

Valamint az aktuális életfilozófiám: mivel én elmaradott faszi vagyok, csak azt hiszem el, amit a vaksi szememmel látok, süket fülemmel hallok és tompa agyammal gondolok. Akkor is ha ez nem ér fel a nagy céljaik igazságához.

Nem félünk! Nem félünk! Itthon vagyunk e földön. Nem félünk! Nem félünk! Ez nem maradhat börtön!

Viccesek ezek az OpenBSD-s srácok, egy tegnapelőtti e-mailben felvetették, hogy gzip-ről át kéne állni xz-re, abból is a v5.6.1-es verzióra, mert az biztonságos: https://marc.info/?l=openbsd-cvs&m=171200100510963&w=2
Nem sokkal később Theo de Raadt, az OpenBSD és az OpenSSH projektek alapítója, beküldött egy olyan e-módosítást, hogy "remove useless whitespace; from Jia Tan"

Nem tudom eldonteni, hogy trollkodnak-e, vagy tenyleg komolyan gondoljak. Mindenesetre az 5.6.1-es verzio RCE-je nem mukodne BSD-n, de egy kesobbi esetleg igen.

https://www.coreinfinity.tech

2024. 04. 01-es dátummal jön a patch.
találgass

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Azért a leírás se semmi.

Enter xz, a modern compression utility for modern binaries. If
gzip(1) is a Subaru Forester that "gets you where you need to go",
xz is a lifted Ford F-250 that "just ran a stop and killed a cyclist".

[ Szerkesztve ]

Tegnap még működött...

Április 1.

.

[ Szerkesztve ]

Munkában beriasztott SLES-re a szekuriti, hogy XZ backdoor, mondok wtf??? De aztán kiderült, hogy egy konténert Tumbleweed-ből épít a beszállító, és abban benne van. Küldtünk neki öklözőzsírt.

-=- There's no place like /home -=-

Használtok SLES-t? Milyen célra? Mi a véleményed róla?

Nekem volt egy Tumbleweed-es gépe, a minap cseréltem le Rocky-ra (de nem a sebezhetőség miatt, amúgy is érett már a csere). És kulcs alapú hitelesítés volt beállítva rajta...

Előtte 10 évig RHEL-t használtam az előző munkahelyemen, az sokkal jobb. Otthon Debiant használok.

Szerk.: Ja, mindenféle alkalmazás, adatbázis, szir-szar azon fut.

[ Szerkesztve ]

-=- There's no place like /home -=-

Miért volt jobb a RHEL? Vagy mi a baj a SLES-sel?

Csak nehogy München 2.0 legyen belőle.

A SLES nem úgy kezeli az alverziókat, mint a RHEL és a Debian, lazán cserélnek csomagokat alverziók közt is, kvázi mintha mind főverzió lenne. 15.5 mikor kijött, marhára nem volt stabil, a supporttal 1 hónapig szopattam magam, míg a végén egy "zypper up" megoldotta a problémámat. Még nem jöttem rá, hogy ugyanaz az install folyamat mikor rak fel exim-et és mikor postfix-et. Ilyenek. Kedvencem az autoyast-os install, mert a lemezeket nem úgy veszi fel, ahogy megkapja a vastól (disk1 -> sda, disk2 -> sdb, stb.), hanem a leggyorsabb lesz az sda, a következő az sdb, stb., tök mindegy, ha azok tök más méretűek.

-=- There's no place like /home -=-

Nálunk is kb. a SAP miatt lett.

Szerk.: Most például azzal szopok, hogy egy gépet kéne újrahúzni, de úgy, hogy maradjon pár régi partició. Na az installer már egy órája homokórázik, mert töröltem egy nem szükséges particiót...

[ Szerkesztve ]

-=- There's no place like /home -=-

Mi a baj az update megoldásaival?

Csodás clickbait cím...

Schleswig-Holstein megint megpróbálkozik a Linux-szal. Jól haladnak 2021 óta...
Majd 2027-ben lesz cikk, hogy már 35000 PC-t váltanak...

Az egészben az a leghumorosabb, hogy a német közigazgatás még minding 90%-ban papíron zajlik. Szóval végső soron nem Windowsról váltanának, hanem papírról.
Mondjuk úgy hogy egyik állam se költ lószart se digitális átállásra, ja lehet az open Source olcsóbb lesz, de ahogy szokásos megint nem...

Szerk: Azt hiszem elolvastam életem legszebb német mondatát.
"Die Zukunft der Verwaltung ist cloudifiziert, automatisiert, algorithmisiert und datenbasiert. "

[ Szerkesztve ]

Faj, bizsereg, viszket?

https://www.coreinfinity.tech

A zyperre gondolsz?

Elhiszem neked.
SLES-t még nem használtam, OpenSuse-n viszont csináltam major upgrade-et is, nem volt vele problémám.
RHEL-alapú disztrók közül Fedorán és CentOS-en upgradeltem, de ott sem volt még probléma (dnf-et használok).

Itthon beágyazottabb a rhel, de IBM óta minden változik... Szóval ezt fogja tükrözni a sok válasz, pebkacok, fudok, "mé nem olyan az összes, mint amit megszokott".

Tegnap még működött...