David A. Wheeler - Shellshock

Titkosítás, biztonság, privát szféra

David A. Wheeler egy részletes összefoglalót készített a bash nemrégiben széles körben nyilvánossá vált Shellshock sebezhetőségéről. Aki csak felületesen tájékozódott eddig a problémáról, annak most egy helyre összeszedte a szerző a legfontosabb részleteket, tudnivalókat. Elolvasható itt.

( Darkcomet | 2014. 10. 09., cs – 17:07 )

Frankó írás.

--------------------------

Csak a viták elkerülése végett. Ha nem használok ékezetet, mobiltelefonról írok.

( ak0sh | 2014. 10. 09., cs – 22:47 )

A Bash ma is frissült Ubuntu 12.04.5 alatt.

[ Shellshock: Bash '14 ]
Kéne egy ilyen FPS, ahol a bozótból előugráló, gonosz backslash szemű bennszülött kódtörő NSA ügynököket lövöldözzük le patch-ekkel, miközben exploitokkal soroznak minket rejtekhelyeikről és repeszbackdoor-okat dobálnak a hátunk mögé. Reggelente Bajor Imre ébreszti a csapatot a rádióban, majd lemegy a 'Piál A Föld' című sláger. Közben kirajzanak az Apache webszerverek, és szórják az égből a commit-okat. Az égi áldás után letérdel a felperzselt földre RMS ezredes, és elhangzik az azóta szállóigévé vált mondata: "I love the regression test in the morning!". A sikeres küldetés végén, maga Linus tűzi föl a pingvintappancsos érdemrendünket a futópadján.

( gmoore | 2014. 10. 10., p – 08:13 )

"Legfontosabb részlet, tudnivaló": soha ne használj Linuxot.

Nem azt vártam, hogy mond meg, hogy mit használjak.
Inkább javaslatot.
Gondolom neked is vannak elképzeléseid, hogy egy kisebb céges környezetben milyen rendszert használnál backup-ra, tűzfalnak, nyomtató szervernek, esetleg levelező szervernek, desktop-nak.
A végén úgyis az dönt aki kialakítja a rendszert de szerintem a hasznos tanácsokat mindenki szívesen fogadja.

----
FreeBSD, Solaris, Debian, LMDE

Gondolom a félszavak odavágása tőled most azért van, hogy minél kevesebb dologba lehessen belekötni.

Szóval, mit is látunk a linken? Esetleg hosszabban is kifejtenéd? Mert lennének vele, meg a fentebb eleresztett FUD-dal kapcsolatban még kérdéseim. Persze, csak akkor van értelme a beszélgetésnek, ha hajlandó is vagy válaszolni.

--
trey @ gépház

"Igen valóban van egy olyan elképzelésem hogy semmiképp se azt, amelyiknek minden fellelhető példányát újra kellett ebben a hónapban telepíteni, ha 1992 óta DHCP kliensként is működött"

Elemezzük ki. Az alapján, amit elmondott, az a feltevése, hogy minden biztonságos, ami nem Linux. Mert minden Linux, ami 1992 óta DHCP kliens volt, az fel van törve.

1) A shellshock nem volt korábban publikus. Persze lehet az a válasz, hogy privátban már tudtak róla 1992-ben és azóta is kihasználják, de ennek a lehetősége vajmi kevés.
2) Ha tudtak is róla, nem biztos, hogy volt hozzá exploit. Ha volt is, nagy számban nem volt kihasználva, mert azt már felfedezték volna.
3) A kihasználáshoz feltört hálózat / DHCP szerver kell. Nyilvánvaló, hogy itt is bukik a "minden példányát". Ráadásul ha 1992 óta piszkálták volna a DHCP szervereket, az is feltűnhetett volna.
4) Feltételezése: csak a Linux érintett. Téves. Ráadásul a Debian, Ubuntu nem használ nem interaktív shell-ként jó ideje bash-t, dash van. Ha pedig az is elég, hogy a bash jelen van a rendszeren, akkor megint csak igaz, hogy nem csak a Linux érintett. OS X-en bash van. Solaris-on bash van. FreeBSD-ken is egy rakat port dependel a bash-ra, ha csak egy is fel van telepítve, bukta.
5) használj mondjuk Windows-t. Ugyan nem sebezhető bash-ra, de DCHP kliens távoli kódfuttatás sebezhetőség szintén érintette az elmúlt években. Hát ez is bukott. Ja? Ilyen sebezhetőség érintette az ISC DHCP klienset is, azaz ha FreeBSD-t, NetBSD-t stb. használtál, az is bukó volt. És akkor ezt még nem is érintettük.

Tehát, akkor ez mitől Linux-only, miért van minden Linux 0wn-olva 1992-től és ha ez szar, akkor más mitől biztonságosabb vagy teljesen biztonságos, az még kérdéses.

--
trey @ gépház

Ez nem a gyakorikerdesek.hu. Akármi is a pontos munkaköröd, egészen biztosan elvárható hogy az utóbbi idők egyik legdurvább (és legjobban dokumentált) linuxos sebezhetőségéről legalább megközelítően pontos információid legyenek. A funkcionális analfabétizmus ("ami 1992 óta DHCP kliens volt, az fel van törve"), a komédiázás ("nagy számban nem volt kihasználva, mert azt már felfedezték volna", "OS X-en bash van. Solaris-on bash van"), és a féltudású marhaság ("ha csak egy is fel van telepítve, bukta") mind gyógyítható, ha szándék van rá.

Ha utánanézni mégis lusta vagy (végülis a cikkben is csak annyi szerepel hogy "Elolvasható itt"), hát elmagyarázom, de akkor készülj fel a mérnöki óradíj megfizetésére.

"linuxos sebezhetőségéről"

priceless

Az általad hivatkozott cikkben csak a negyedik sorig kellett volna eljutni:

"and DHCP clients connecting to subverted DHCP servers. The probability of vulnerability was somewhat less on Debian and Ubuntu, because their default non-interactive shell is dash (which was not vulnerable) instead of bash, but there were still cases where they could be vulnerable."

Innen akár folytathatjuk is a FUD-od elemézését, ami a rend kedvéért így hangzott:

"minden fellelhető példányát újra kellett ebben a hónapban telepíteni, ha 1992 óta DHCP kliensként is működött"

Tehát gmoore szerint minden DHCP szerver fel van törve, azon keresztül az összes linuxos kliens own-olva van (ha van benne bash, ha nincs, ha az az alapértelmezett, ha nem) és a többi faszság.

--
trey @ gépház

És a "subverted" szót még mindig sikerült úgy átugrani, hogy bold-dal ki volt emelve. Afelett is elsiklottunk, hogy mitől "linuxos" a sebezhetőség és még mindig nem tudjuk, hogy gmoore szerint mi a megbízható, amit mondjuk az elmúlt években ugyan nem így, de máshogy DHCP-n keresztül kódot lehetett futtatni.

Nem csak a subverted szó volt bold, hanem a te állításod is, amitől a vita indult.

--
trey @ gépház

Najo, csak ebbol ugy gondoltam, tobb DHCP szerveruk van.
"melyiknek minden fellelhető példányát újra kellett ebben a hónapban telepíteni, ha 1992 óta DHCP kliensként is működött."

Persze a legegyszerubb ujratelepiteni, de ez windowsos szokas.
De miert a salest bizzak meg vele? Nem telik sajat adminra? Vagy berelni egyet egy cegtol? Nem ertem.

UPDATE: AAAAAAAAA, most olvasom, dhcp kliensekrol van szo.
Akkor lehet, hoyg tenyleg csak egy szerveruk van meg ket kliens. Vagy nem tudom.
De urjatelepiteni? Ez egy kicsit eros.

--
http://www.micros~1

( Zahy v | 2014. 10. 10., p – 12:30 )

Itt már ragoztam egy darabig a dolgot, de hátha elsikkadt, vagy itt végre valaki megcáfol. Ma egy elvileg javított bash-t használó környezetben újra ellenőriztem amit korábban rinyáltam, hogy ez a shell-függvényesdi azért ha nem is feltétlenül távolról kihasználható, de lokálisan azért még mindig vannak veszélyei. Ebben a rendszerben az a fajta javítás van, ami a BASH_FUNC_xyz() nevű és '() {' kezdetű változókat tekint exportált függvénynek. (Ha jól tudom a hivatalos bash-javítás BASH_FUNC_xyz%% -ot tekinti annak.)

zgabor@linux-hp-zahy:~> echo $SHLVL
1
zgabor@linux-hp-zahy:~> env 'BASH_FUNC_ls()=() { echo vulnerable;}' bash
zgabor@linux-hp-zahy:~> echo $SHLVL
2
zgabor@linux-hp-zahy:~> type ls /bin/ls
ls is aliased to `ls $LS_OPTIONS'
/bin/ls is /bin/ls
zgabor@linux-hp-zahy:~> ls
vulnerable
zgabor@linux-hp-zahy:~> exit
zgabor@linux-hp-zahy:~> env 'BASH_FUNC_/bin/ls()=() { echo vulnerable;}' bash
bash: error importing function definition for `BASH_FUNC_/bin/ls'
zgabor@linux-hp-zahy:~> echo $SHLVL
2
zgabor@linux-hp-zahy:~> type ls /bin/ls
ls is aliased to `ls $LS_OPTIONS'
/bin/ls is /bin/ls

Lefordítom. Elérési úttal adott parancsot már nem tud lokális felhasználó felüldefiniálni, ellenben minden parancs amit path megadása nélkül használ az ember, az védtelen. Eddig csak egyetlen ellenötlet jött, hogy /etc/profile-ból minden parancsból alias-t csinálok alias ps=/bin/ps stílusban, sajnos az se működik, mert az alias belső parancsa a shellnek, és mint ilyen később vizsgálná meg a rendszer, mint az általam kellően preparált shell-függvényeket. (Fenti példában BASH_FUNC_alias() .... vagy másoknál BASH_FUNC_alias%% ... környezeti változóval tesztelhető :-) )

A bash-ben ket dolgon valtoztattak:

1. a parser bugos volt, ezert vegrehajtott kodot is a fv-definiciok feldolgozasakor

2. barmilyen valtozoban lehetett fv-definiciot atadni, most mar kapott egy prefixet, amit egyetlen ismert rendszer (pl. apache) sem hasznal, igy tovabb csokkent az esetleg meg mindig meglevo parser bugok kihasznalasanak eselye

Ami a fuggvenyek / kulso parancsok / builtinek nevutkozeset illeti, abban nem volt valtozas, es nem is lesz, az environment beallitasa mar a felhasznalo dolga marad. Aki tutira akar menni, teljes eleresi uttal kell, hogy hasznalja a parancsokat, kulonben nem garantalt az elvart mukodes, lasd pl. builtin parancsok es $PATH (plane Solarison, ahol nem ritka ket ugyanolyan nevu, de egesz mas mukodesu binaris, nagyon nem lenne mindegy, melyik utvonala van elorebb a PATH-ban).

A linkelt morgolódásomban leírtam, hogy ezzel csak az a baj, hogy amíg nincsenek ilyen baromságok, mint exportált shell-fv, addig elég volt jól beállítani a PATH-t (lásd PATH=/usr/ucb/bin:/bin vagy PATH=/usr/sysv/bin:/bin - nyilván a nevek nem feltétlen korrektek), és máris az futott le, amit akartál. Ellenben az exportált shell-függvénnyel *lokálisan* teljes mértékben kezelhetetlen környezet áll elő, ugyanis *minden* parancsot (még a belső parancsokat is) felül lehet definiálni - javítás után már csak és kizárólag a /teljes/úttal/megadott/parancsok azok amiket *nem* tudsz felüldefiniálni - de a többit változatlanul.
Ja, tudom, nincs olyan hogy lokálisan van júzer, meg nincs olyan, hogy valakiben megbízik a rendszergazda. De.

A kornyezeti valtozon keresztuli fv-atadast nem mindenki akarta kikapcsolni, ezert megmaradt a lehetosege. A kornyezeti valtozok becsempeszese ellen korabban is csak a kornyezet validalasa (apache, ssh, sudo, ...) vedett. Latsz meg olyan tamadasi vektort, ami mukodik? Ne olyat mutass, hogy te magad allitasz be valtozokat, hanem olyat, ahol ez a rendszer uzemeltetojenek a tudta es tevoleges hozzajarulasa nelkul tortenik meg.

Az EDITOR/VISUAL az annyiból speciális, hogy ahhoz kell valamit csinálni (értsd spéci parancsokat futtatni - gondatlanul beállított környezetben). Ehhez a problémához sajnos semmit, hisz bármelyik parancsot felül tudom definiálni. Ezért ugatom, hogy az átlag környezeti változós problémánál ez komolyabb.