David A. Wheeler - Shellshock

 ( trey | 2014. október 9., csütörtök - 7:35 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Frankó írás.

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

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

+1

------------------------------------------------------------------------------
www.woodmann.com/searchlores/welcome.htm

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.

Standup karrierbe ne kezdjél. Ez nagyon rossz volt.

--
trey @ gépház

Ez jo ! Reszemrol tamogatom a stand-up karriered egy nagyon eros szobeli ballveregetessel :) !

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

Merthogy a bash az Linux-only stuff. Vagy ha nem ezért, akkor kifejtenéd?

--
trey @ gépház

De, azért.

Jól kifejtetted! Köszönöm!

--
trey @ gépház

Akkor mit használjak linux helyett (otthoni és céges környezetben)?

----
FreeBSD, Solaris, Debian, LMDE

Ha másoknak kell ezt megmondani, akkor teljesen mindegy.

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

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.

"ha 1992 óta DHCP kliensként is működött."

Tehát akkor se Linux, se OS X, se Solaris, se Windows, se *BSD.

gmoore biztonsági szakértő javaslata a <dobpergés> a .....

--
trey @ gépház

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

Bocsánat.
Nem kötekedni akarok, de minden op.rendszernek vannak hibái.
Csak arra lettem volna kíváncsi, hogy akkor mit használnál, hogy kevesebb legyen a szívás.

off
1992-2014 --> 22 évente sötétség
on

----
FreeBSD, Solaris, Debian, LMDE

"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

lock

Ez nem sok minden válasznak, azt ugye érzed "gmoore".

--
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

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762923

Nosza, folytasd (illetve hát kezdd el végre) az "elemzést".

A másik bekezdésre: http://a.te.ervelesi.hibad.hu/szalmabab. Tudom, nem fogod érteni, hogy miért.

É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

"nem tudjuk"

Javítva: a jaszkari még mindig nem tudja. Ez meg elég érdektelen.

Az elemzés is jön majd akkor, vagy csak a tipográfiai tudásoddal kell megelégedni?

"nem tudjuk"

Itt várják a válaszod cirka 9 óta.

--
trey @ gépház

Miert nem alkalmaztok rendszergazdat?

--
http://www.micros~1

Amekkora infrastruktúrára én gondolok felesleges +1 ember.

----
FreeBSD, Solaris, Debian, LMDE

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

Persze, erős, dehát a feltöretlenségben vakon bízni (openssl+bash+hamarosan_jön után) is az. Csak az egyik célravezetőbb.

Kb, mintha ezt írtad volna:
"Mindenki bűnös, amíg ártatlanságát nem tudja bizonyítani."
Durva.

--

nTOMasz
"The hardest thing in this world is to live in it!"

Az openssl sebezhetoseg nem tett lehetove tavoli kodfuttatast tudtommal.

Na jó, de DHCP szerverükkel kell kezdeni, mert a feltételezés ugye az, hogy azt is felnyomták. Vagyis a világon mindegyiket, amihez bugos Linux kapcsolódik. Így szól a FUD.

--
trey @ gépház

Erre már feliratkozok. :)

+1

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.

Fent már leírtam: ahol van felhasználó a gépen és annak van rendszergazdája, ott ez működ*het*. Mivel én nem security hanem használhatósági szempontból nézem a dolgot, nem keresek támadási vektort, majd keres helyettem más. Számomra veszélyesebbnek tűnik, mint hasznosnak.

Azt ne feledd, hogy ha mások környezetébe teszőleges környezeti változót be tudsz csempészni, akkor már meg van baszva a dolog bash nékül is. Pl.: EDITOR=/tmp/gotcha.sh

Biztonsági szempontból ez nem új felfedezés.

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.