rm -rf Steam vulnerability

Spouštěč aplikace Steam pro Linux může v některých případech smazat veškerá uživatelská data. Podrobněji například zde, neoficiální patch tady.

18.1.2015 14:02 | Michal Makovec | Bezpečnostní upozornění

Komentáře

[Blaazen]

rm -rf "$STEAMROOT/"* could be evaluated as rm -rf "/"* if $STEAMROOT is empty

:D

[Jendа]

Ještě štěstí, že všechny operační systémy používané v roce 2015 mají verzování souborů a undelete, takže je obnova po této chybě otázkou jednoho příkazu. Oh wait.

[Sten]

Které systémy to mají?

[Jendа]

Proto Oh wait.

Prý VMS, ale nikdy jsem to neviděl.

[Sten]

V Linuxu to umí NILFS, ale moc se nepoužívá. Pro řešení problémů s instalací či odinstalací (nejen Steamu) je hodně dobré apt-btrfs-snapshot.

[Jendа]

apt-btrfs-snapshot

Hezké, umí je to taky expirovat, nebo si to musím napsat sám?

Já jsem došel k tomu, že asi budu držet pětiminutový snapshot a pět hodinových, pět denních, týdenních a měsíčních. To se dá realizovat pár řádkama v bashi a crontabu.

[Sten]

apt-btrfs-snapshot je expiruje automaticky.

[Lol Phirae]

Takhle blbost na žádném normálním systému nic nesmaže asi tak od roku 2006.

[----]

to "opraví" jen "rm -rf /", ne "rm -rf /*".

[Ovoce]

IO v Steamu na Linuxu prý bylo/je totálně zfetované, soudě podle jednoho člověka, s kterým jsem se nedávno bavil na irc... prý to při instalaci/stahování všecko píše jako 16TB soubory a pak je při každém zápisu na disk zase hned truncatuje... už si nepamatuju ty podrobnosti, ale prý to hodně zabíjelo IO systému a vytěžovalo CPU.

[Ovoce]

Jinak v odkazovaném vlákně jsem našel toto, aby snad nevznikla mýlka, že Steam na Windows je snad inteligentnější. Jako vole... fakt čistej způsob odinstalování, to musel vymyslet regulérní pošuk. Nezkontroluju si, co vlastně mažu, ale hlavně aby po mě nic nezbylo a byl ordnung. Nedivil bych se, kdyby takovej člověk ještě použil nějakou bezpečnou metodu mazání :)

[Lol Phirae]

Jako vole... fakt čistej způsob odinstalování, to musel vymyslet regulérní pošuk. Nezkontroluju si, co vlastně mažu, ale hlavně aby po mě nic nezbylo a byl ordnung.

A čemu se divíš? Dyť to anoncujou jako "the ultimate entertainment platform"

[JoHnY3]

Tohle chovani je pod widlema jeste docela bezna vec. Je to prasarna, ale on za to steam tak uplne nemuze. Binarka hry si muze ve svym steamapps a v podstate i mimo nej delat co chce a hry jsou vrchol nekvality. Diky tomu je smazani vseho ve svem adresari vazne jedinej rozumnej zpusob jak po sobe nenechat klidne 10GB bordelu. Na druhou stranu mi neni jasny proc Steam pri instalaci nezabrani takovy zakladni chybe jako instalace primo do Program Files.

Vrchol tehle chyby jsem potkal u instalatoru binarek betaverze nejakeho starozitneho PHP kdysi na Windows 2000. Kvuli kompatibilite s IIS (web server od MS) se muselo phpts.dll a par dalsich filu instalovat primo do C:\WinNT\System32. Nu a pri odinstalaci to udelalo co? Smazalo to po sobe prece vsechny adresare kam se nahraval nejaky soubor ... takze pekne za chodu vsechno v system32. OS mi po asi minute zamrznul a pri nasledny reinstalaci windows a vsech aplikaci jsem byl hoooodne sprostej. Na novejsich Windows by dneska mozna zabralo recovery, ale tehda to bylo bez sance. Zvlast kdyz bez SxS hazela do system32 svoje dllka kdejaka aplikace.

[David Watzke]

Od doby co se živím adminováním si na tyhle věci ve skriptech dávám velký pozor. Dobrej pomocník v bashi je "set -u":

$ set -u
$ rm $empty
bash: empty: unbound variable

Jsou skripty, které bych bez podobných opatření vůbec neměl odvahu vypustit do světa, zejména když se mají spouštět neinteraktivně / automaticky a něco mažou.

[Ivorne]

Ten 'set' má hustou manpage. Pořád tam používaj výrazy 'shell' a 'shall'. :D

"A non-interactive shell shall immediately exit. An interactive shell shall not exit."

[Ovoce]

An interactive shell shall shell the non-interactive shell with artillery shells until the shell of the non-interactive shell shall shell out all its Shell shares to the interactive shell.

[...]

shall I shell out the shell?

[mankind_boost]

Už aby ten shell poshell.

[kralyk z abclinuxu]

How many shells shall shell shell, should shell shell shells?

[Ovoce]

Shell shall shell until shellsock shall occur.

[Nicky726]

Na to mě napadá jen: „Buffalo buffalo Buffalo buffalo Buffalo buffalo Buffalo buffalo Buffalo buffalo“

[Matlák]

Tak nějak. Nejlepší kombinace je asi set -euo pipefail na začátku každého scriptu. On je jinak shell pěkně nebezpečná hračka.

[David Watzke]

-e a -o pipefail jsou někdy užitečný, ale že bych je cpal do každýho skriptu, to taky ne.

Např. obyčejně nechci, aby se mi ukončil skript kvůli něčemu jako:

grep nomatch file | tee outfile

U set -u si zas člověk musí dávat bacha na to, že tohle neprojde:

[[ -z "$empty" ]] && echo "\$empty je prázdná"

a je potřeba to obcházet (např. pomocí ${empty:-})

[Jardík]

Aby ty tvoje skripty pak fungovali i někde jinde než bashi. Nesnáším skripty závislé na balastu jménem bash.

[Lol Phirae]

Nesnáším skripty závislé na balastu jménem bash.

No, někdo jiný zas nemá náladu babrat se s tupými shelly, že. Když si pustíš #!/bin/bash skript pod jiným shellem a nebude ti fungovat, tak hádej, kde bude chyba.

[little.owl]

+1

[----]

když už, tak #!/usr/bin/env bash.

[Lol Phirae]

Debata vo exkrementu...

[pavlix]

Důvod?

[----]

lepší portabilita (env je v /usr/bin vždycky, bash vždycky v /bin není, třeba na mém systému (pokud vůbec je) je v /usr/local/bin)

[pavlix]

env je v /usr/bin vždycky

Dle jakého standardu?

[David Watzke]

env je v /usr/bin vždycky

Tohle jednoduše není pravda.

[David Watzke]

To je ideální, když je pak někde "env" pouze v /bin.

[pavlix]

Aneb jak převést problém na zcela ekvivalentní problém. Kdyby se lidi chytili za hlavu a do shebangu šlo psát identifikaci interpretu namísto lokace, tedy například bash, který by se našel přes $PATH, nemuseli by lidi prosazovat takové špinavé triky jako volat úplně jiný interpret.

[----]

shebang PATH nečte. Cesta ve shebangu je absolutní cestou k binárce interpretu.

[pavlix]

Captain Obvious?

[David Watzke]

Jen jestli by to nepřineslo víc problémů než užitku. Pak ti nějakej skript přidá do PATH cestu, která obsahuje jinej bash, zavolá další skript a už se bude hůř dohledávat proč se co a jak stalo.

Podle mě by to nějakým způsobem mělo spolupracovat s /etc/shells, s tím že by se ještě musel vytvořit ekvivalent tohoto souboru pro ostatní interpretované jazyky - např. /etc/interpreters.

Pak by systém narazil na #!bash, udělal něco jako "grep '/bash$' /etc/interpreters" (v C ) a věděl by jak to spustit.

[pavlix]

Můj názor je, že proměnná PATH je tam právě od toho, abych si mohl říci, kde chci hledat software, který chci používat. Pokud si ji nastavím na cestu k nějakému jinému shellu, většinou mám pro to dobrý důvod. Pokud napíšu skript, který toto udělá, většinou k tomu mám dobrý důvod. Nemám nic proti nástrojům, které vodí uživatele za ručičku, ale základní systém bych radši aby se choval pokud možno konzistentně. Když zavolám python x.py, taky se to zavolá v Pythonu z $PATH a nebavíme se o tom, že je matoucí, že by ta cesta mohla být nastavená nějak špatně.

Stejnětak můžu mít špatně nastavenou proměnnou LD_PRELOAD a neuděláš nic.

[David Watzke]

Asi máš pravdu, no. Zrovna tak když uvedeš v shebangu absolutní cestu, tak to nevypovídá nic o tom, jak byl skript skutečně zavolanej. Takže na tom něco je.

[pavlix]

Navíc je potřeba si uvědomit, že alternativou k tomu je zde zmíněný /usr/bin/env python, což je jenom prasáčtější verze toho, co navrhuju :).

[David Watzke]

Jo, to si uvědomuju - ostatně jsem to i chtěl konstatovat. Jen jsem polemizoval s tím, zda je tvůj návrh opravdu zdokonalením dobrého, špatně implementovaného nápadu... anebo třeba bezpečnostní riziko. Teď mě nic tak hroznýho nenapadá, ale to nic neznamená

[pavlix]

Můj (i když jistě nebudu první, jednou mi to snad v nějakém prostředí i zafungovalo, když jsem to testnul) nápad nenahrazuje absolutní cesty, ale přidává možnost je nepoužít. Trik s env je pak zcela zbytečný. Já osobně bych pak využití absolutních cest skutečně značně omezil, pokud bych nenašel zásadní důvod proti. Jako jedinou zásadní nevýhodu vnímám tu dobu, než se bude moci říci, že to funguje všude.

[lertimir]

Také obzvlašt vypečená proměnná je LD_LIBRARY_PATH. Před cca 15 lety jsem viděl útok na systém s FTP zápisem (a přebráním LD_LIBRARY_PATH od klienta) tak, že útočník uploadnul knihovnu používanou login daemonem na server (už si npamatuji co to přesně bylo). Lokálně si změnil LD_LIBRARY_PATH na cilový adresář s knihovnou a při přihlášení k systému najela tato jeho knihovna a bylo vymalovano.

[Josef Kufner]

Nebo když chceš spustit skript pro opravu /usr, které se nepovedlo připojit.

[pavlix]

Tenhle problém už je na lenartoidních systémech vyřešen :).

[----]

v každém systému, na který jsem narazil, je env v /usr/bin (to zahrnuje spoustu distribucí Linuxu, *BSD apod.)... zato bash je v /bin jen někde.

[little-drunk-jesus]

tech systemu par je , treba:

IBMUSER:/u/ibmuser: >uname -a
OS/390 ADCD 20.00 03 3090
IBMUSER:/u/ibmuser: >ls -l /usr/bin/env
ls: FSUM6785 File or directory "/usr/bin/env" is not found
IBMUSER:/u/ibmuser: >ls -l /bin/env
-rwxr-xr-x   2 START2   SYS1       98304 Jun 11  2008 /bin/env

[----]

i tak platí, že pravděpodobnost toho, že "env" je v /usr/bin, je větší, než pravděpodobnost bashe v /bin. Má OS/390 vůbec bash?

[pavlix]

Přesně, jak jsem říkal, řešíme pravděpodobnost výskytu nástrojů jen kvůli debilnímu designu.

[little-drunk-jesus]

Ano ma, ale neni defaultne nainstalovan podobne jako na AIX nebo HP-UX. Ja vim, ze je to extremni pripad, ale... :)

[David Watzke]

Přesně tak. Omezovat se nějakým sto let starým subsetem funkcí fakt nemám zapotřebí (a není pro to důvod). Jiná věc je, že se v bashi vyhýbám používání speciálních featur z posledních verzí, protože na serverech nějakou dobu nebudou.

[kralyk z abclinuxu]

To mi připomíná onen legendární bug...

[Lol Phirae]

Fuck you, nVidia...

[Jendа]

What if Linus Torvalds is just angry because he's had to use Linux for 20 years

[Karel]

A tak schválně - jak dlouho to bude trvat, než se to opraví? Resp. bude to vůbec opraveno? ))

[Sten]

Opraveno to už bylo:

if [ "$STEAMROOT" != "" ]; then
rm -rf "$STEAMROOT/"*
fi

[Lol Phirae]

To jsme si moc nepolepšili, že... Příkladno, představ si, že to nainstaluješ do /opt nebo přímo do $HOME.

[Sten]

Už to alespoň dělá to samé, co ve Windows

[AsciiWolf]

[Lol Phirae]

Pravda, taky pokrok.