Így törölte a Steam a teljes root-ot... tanulságos!

Security-all

https://www.youtube.com/watch?v=qzZLvw2AdvM

  • 1803 megtekintés

( dragi v | 2024. 01. 22., h – 12:57 )

Szerintem ehhez rootként kellett futtatnia ami eleve fura, meg ntfs-re mozgatta amit noexeccel mountolt. Nincs itt semmi látnivaló.

Lehet 777-et tolt az egész drivera, mert nem értette hogy műdik. Kb minden témánál, amikor technikai user alól futó szolgáltatás fájljait akarják elérni, akkor vagy rootként próbálják, vagy átjáróházra állítják a jogosultságukat ahelyett, hogy a felhasználójukat a csopporthoz adnák.

Nem volt jogosultsága. A YT videó címe félrevezető. Emlékszem erre a történetre. Csak a saját fájljait "vesztette el".

 

Idézet az Original bug reportból:

Until I looked and saw that steam had apparently deleted everything owned by my user recursively from the root directory.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

Nem, ti értitek félre. A root alatt nem vitt mindent, csak a /home alatt, de az is elég. Nyilván amihez nincs jogosultsága a felhasználónak, azt az rm nem törli, arra hibákat írogat, viszont ami törölhető, azt kímélet nélkül törli. /home alatt megy a levesbe a teljes felhasználói profil, az összes programbeállításokkal, letöltésekkel, dokumentumokkal, stb., ha van oda csatolva valami, akkor az is megy az örök bitmezőkre.

Az rm-nek hiába van ott alapértelmezettnek a --preserve-root, viszont a --preserve-root=all és a --one-file-system kapcsolók nem alapértelmezetten feltételezettek, pedig annak kéne lenniük szerintem. Ráadásul ezek is csak a GNU változatban vannak jelen, mivel nincsenek a legújabb POSIX szabványban sem, a BSD userland rm binárisában nincsenek ilyen normivédő kapcsolók, az mindent küld alapértelmezetten a levesbe, / -ot, bárhová alá csatolt más fájlrendszereket is.

Rendszert nekem is sikerült szétcseszni, de nem rm-mel, hanem chmod-dal, rekurzívan akartam kiadni a ./ mappára, de félregépelés miatt a /. helyet gépeltem be neki, ráadásul sudo-val ment. Végül helyre lehetett hozni, de nem kis bosszúság volt. Olvastam felhasználókat, akik rosszul felparaméterezett hdparm paranccsal meg meghajtókat vágtak haza firmware szintjén téglásítva. Ezek a low level tool-ok, nem ismernek kegyelmet, nincs bennük általában kellő védelmi mechanizmus sem, megcsinálnak bármit vakon, feltételezve, hogy hozzáértő és olvasni-gépelni pontosan tudó emberke használja őket.

A rossz meghajtó felül dd-zését meg nem is kell senkinek bemutatni, örökzöld klasszikus, user szépen reflexből nyomatja a /dev/sdb-re, amit akar, csak épp ha a rendszerben bootkor helyet cserélt az sda-val, akkor game over. Én ezért minden dd előtt lekérek egy lsblk kimenetet is. Bár a mostani rendszeremben csak /dev/nvme kezdetű drive-ok vannak, /dev/sdakármi csak akkor, ha külső meghajtót csatolok.

“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.”

( pehsa | 2024. 01. 22., h – 14:30 )

Amúgy ez nem egy ritka hiba. Anno volt egy fejlesztő kolléga, aki szintén csinált ilyet ERP rendszer fejlesztése során. A rendszer saját nyelvéből hívott meg shell parancsokat és nagyjából a következő történt:
 

val mandant = "./prod/"
val tmpfolder = ""
if (..) then
  ..
  $tmpfolder = "temp/"
  ..
end if
val törlendő 
törlendő = $mandant + $tmpfolder + "*"
rm -rf $törlendő

Csak egyszer kellett egy olyan eset, hogy az IF ne teljesüljön és jött a hideg zuhany.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

láttam én is hasonlót, ott úgy jött ki, hogy win-es sorvégjelek miatt elszált egy script, ezért a konfig fájlt átmásolta win-re ott notepad++-szal átalakította. Majd visszamásolta, de rossz userrel. És így a futtatott script nem érte el a tartalmát a konfignak, ami kiadta üresnek a változót és így kijött az rm -rf /*. Persze csak a user összes fájlát tudta törölni, nem 777 és nem root userrel futtatta. Szóval inkább a változókra kell ellenőrzés, mert a user mindig tud olyan kreatív lenni, hogy kijöjjön az önmegsemmisítés.

Nagyon ritkan van szukseg rm -rf parancsra. Nekem egy ilyen scriptem volt, es ott eleg heurisztikus is volt az utvonal, raadasul tobb helyrol is kellett hivni, ugyhogy en kraktam az rm parancsot egy kulon fugvenybe, es hivas elott ellenoriztem, hogy a parameter megfelelo-e.

IMHO tokmindegy, hogy all fejre, a durva parancsokat mindig korul kell bastyazni.

Nekem van ketto ilyen laptopom. Alapvetoen az intelt hasznalja minden, kiveve ha hozzateszem, hogy "__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia <blablahblahaz eredeti parancs, pl. hogy steam>". Mert ilyenkor az nvidia kartyamat hasznalja.

Nem nagyon kell valtogatni. Bar a system76-omon lehet a "system76-power graphics <melyiket akarom>" paranccsal (bar van grafikus valto is).

( Nyosigomboc v | 2024. 01. 22., h – 20:34 )

Nekem ez a kedvencem:

clean:
        rm -rf akarmi akarmi.o /* This will remove the files */

A strange game. The only winning move is not to play. How about a nice game of chess?

Darwin-díjas, valakinél túlműködtek a C-s reflexek. Védelmére legyen mondva, hogy előre odakommentelte, hogy a fájlok el lesznek távolítva, csak éppen az összes létező.

“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.”

( Raynes v | 2024. 01. 22., h – 22:07 )

Én egy nagyon hasonló hibát pár napja láttam a redditen, ahol a felhasználó kézzel adott ki egy nagyon hasonló parancsot, csak a változó neve volt más, de épp úgy üres volt, és a / -re futott le az egész. Semmi köze nem volt a Steam-hez. Ez teljes egészében coder/user error, nem győződik meg, hogy a változó üres-e. Tény, hogy tanulságos esetek ezek.

“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.”