Vlákno názorů k článku Díra v bashi, které si 20 let nikdo nevšiml od Mirek - Root opet nezklamal, stejne jako v pripade Heartbleed. Kdyz...
-
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ÁNKY DO MAILU