[Frissítve] Kritikus Linux desktop biztonsági problémára figyelmeztet az Invisible Things Lab

Bug

Joanna Rutkowska, a Invisible Things Lab vezetője tegnap egy blogbejegyzést írt "Rejtett csontvázak a Linux szekrényében: a Linux desktop-od r00tolása profitért és a mulatság kedvéért" címmel. A blogbejegyzésben Joanna arról ír, hogy kollégája, Rafal Wojtczuk, miközben a Qubes-on (1, 2) dolgozott, egy érdekes, Linux-on privilégium-szint emelést lehetővé tevő támadással állt elő. Joanna szerint sikeres exploitálás esetén a támadás a felhasználót root jogokhoz juttatja.

Joanna Rutkowska

A támadás lehetővé teszi az X szerverhez hozzáférő, privilégiumok nélküli felhasználói processz számára, hogy az feltétel nélkül root szintre emelkedjen. Ráadásul úgy, hogy eközben gyakorlatilag semmilyen konkrét X szerver bugot sem használ ki.
Más szóval, ha bármely GUI-s alkalmazást (pl. egy sandbox-ba zárt PDF olvasót) sikeresen megtörnek, akkor az összes Linux-ba épített biztonsági mechanizmus megkerülhetővé válik és root jogokhoz juthat a támadó. Rutkowska szerint a támadás lehetősége évek óta jelen lehet, erősen valószínű, hogy azóta, hogy a 2.6-os kernel bemutatkozott.

A támadás pontos leírása elolvasható Rafal dokumentumában.

Joanna szerint a Qubes (1, 2) architektúra megtervezésekor az elsődleges szempontok egyike pont az ilyen támadások lehetőségének kiküszöbölése volt. Véleményük szerint a Qubes sokkal biztonságosabb a sandboxing mechanizmusoknál, mint a BSD jail vagy a SELinux-alapú sandbox megoldások).

A kernelproblémára Linus augusztus 13-án elkészítette a javítást. A Red Hat figyelmeztetőt adott ki, amelyben "high"-ra értékelte a hiba súlyosságát.

Brad Spengler úgy tűnik, hogy exploitot írt a problémára.

A blogbejegyzés itt olvasható.

Frissítés: A blogbejegyzés hozzászólásai közt Brad Spengler utal arra, hogy Linus elszabta a javítást, így a javításra a következő "stable" kiadásig várni kell, vagy git-ből ki kell szedni az adott commit-eket. A hozzászólásokban Spengler látszólag megkérdőjelezi az Invisible Things Lab fejlesztéseinek hasznosságát is.

Lesz ez még durvább is megérzésem szerint. Főleg ha figyelembe veszem Linus security-hez való viszonyát.. Én mindenesetre készítem a pop-corn-t..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Továbbra sem a kernel hibákban látom a legfőbb problémát. Desktop-on sokkal jobban aggasztanak engem az alkalmazások biztonsági hibái. Azokkal kellene valamit kezdeni. Leszarom ha root lesz a gépemen valaki, ha már minden adatomhoz hozzáfért egy böngésző bugon keresztül. Ez az egész szoftverfejlesztés a mai színvonalon, fejlettségi fokon egy vicc. Az egészről a toldozás-foltozás és a barkácsolás jut eszembe.

--
trey @ gépház

Azért vegyük külön a szerver és a desktop alkalmazást pls. Desktopon valóban igazad van, mert ott a root csak az alap adminisztrációs tevékenységekhez kell, amúgy meg nem használod, így szinte minden személyes cuccod a saját userID-d birtokában van, ergo persze hogy az azonos privilégiummal futó app simán hozzáfér az adatokhoz.

Egyedül akkor okoz ez neked problémát, ha a gépen több user is van, mert akkor egy ilyen (akár böngészőn keresztül indított ) exploiton keresztül aztán hozzáfér a támadó mindenhez ( az összes user személyi adatához, ami több useres gép esetén viccesebb )

Szerver esetén viszont a dolgok kicsit másként mennek - A manapság elterjedt támadási vektorok nem játszanak, vagy ha még is annyi esze volt az adminnak, hogy felrakott egy X-et, meg mondjuk egy firefox-ot a szerverre, akkor se fogja tudni kompromittálni a szervert egy általad említett hiba esetén, mivel minden fontos a root-nál van, vagy más applikációs userID alatt.. Egy ilyen hiba esetén viszont az egész mindenség nyitva áll a támadó előtt, szóval ott az ilyen fajta támadások különösen veszélyesek tudnak lenni.

Amúgy már párszor elmondtam, de ahogy nézem még mindig áll az, hogy amíg Linus nem figyel oda normálisabban a security-re, addig hiába "bazár elv", meg "open source", meg "több szem többet lát" - xart se fog érni, pont azért mert akinek van is annyi tudása, hogy átlássa és meg is értse a kódot, plusz tudja hogy mit érdemes auditálni az általában az ilyen kis finom hibákat meg is tartja magának, és csak a ritkább esetekben teszik közkincsé (Csak nézd meg azt, hogy ezt a hibát mikor fedezték fel). Innentől a többi ember meg max bugfixeket ír funkcionális hibákra, oszt csókolom: a normális auditing és programozási irányelvek nélkül az egész "Linux security nevű moslékot" le lehet húzni a WC-n.

Mondjuk egy dolgot még hozzá kell tegyek a teljes körképhez: Azoknál a szervereknél, ahol tényleg fontos is, hogy valami security szerűség is legyen, ott nem vanilla kernelt futtatnak, hanem agyon-security-patchelt kernelt, bár ez se garantál egyáltalán teljes biztonsági szintet.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

"Azoknál a szervereknél, ahol tényleg fontos is, hogy valami security szerűség is legyen, ott nem vanilla kernelt futtatnak, hanem agyon-security-patchelt kernelt, bár ez se garantál egyáltalán teljes biztonsági szintet."

Enterspajz kornyezetben ez not supported, de ha az lenne, lehet, hogy megnehezitene adott szoftver uzemelteteset, vagy lehetetlenne is tenne.

Nézd majd meg egy Redhat Enterprise server kerneljét... Az már by default agyon van patchelve..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nem azt írtam, hogy nem tartom problémának, hanem azt, hogy nem ezt tartom a legfontosabb problémának. Ég és föld a különbség a kettő közt.

"Azért vegyük külön a szerver és a desktop alkalmazást pls."

Természetesen különvettem. Ezért kezdtem úgy, hogy "Desktop-on sokkal jobban ..."

--
trey @ gépház

Jogos.. Ezen valahogy átsikolottam.. Viszont ha csak ennyi bajod van akkor egy apparmor bőven elég neked az adatok védelmére :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( zsirmo v | 2010. 08. 18., sze – 09:57 )

Azert jo latni, hogy a BOSS( Linus :P) , figyel es kodol, ha szukseges :P

( c4nn1b4l | 2010. 08. 18., sze – 10:08 )

Made my day. :)

"(...)they make such a big deal about concentrating on security(...)"
- Linus

( turul16 v | 2010. 08. 18., sze – 10:01 )

EPIC

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( wowbagger v | 2010. 08. 18., sze – 10:33 )

Ha jól látom a bug csak a 32/64 bites multilib-es rendszereket érinti?
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 13.1 | 2.6.34.1-janos

Az exploitban ez áll: 


/* known for over a year, fixed in grsec
   bug is due to a bad limit on the max size of the stack for 32bit apps
   on a 64bit OS.   Instead of them being limited to 1/4th of a 32bit 
   address space, they're limited to 1/4th of a 64bit address space -- oops!
   ...
*/

Értelmezésem szerint tisztán 32 és 64 bites rendszereknél a fent leírt dolog nem jöhet elő.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 13.1 | 2.6.34.1-janos

( csuhi | 2010. 08. 18., sze – 11:09 )


[csuhi@csuhainote temp]$ gcc 64bit_dos.c -o 64bit_dos
[csuhi@csuhainote temp]$ ./64bit_dos
execve failed
[csuhi@csuhainote temp]$ uname -r
2.6.33.6-147.2.4.fc13.x86_64
[csuhi@csuhainote temp]$ cat /etc/redhat-release
Fedora release 13 (Goddard)

Elrontottam valamit, vagy ilyen sz@r ez a linux hogy má rendes exploitot se bírnak rá írni? ;)

--
http://csuhai.hu
http://sys-admin.hu

És szerinted mit kellene csinálnia? Nyilván nem fognak olyan exploitot kiadni, amit Pistike is használhat módosítás nélkül apuci szerverén. :)

Szóval ide kattints: http://dawn.royalcomp.hu/~raas/lc.html

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

a proof of concept-nek nem ez a lényege? :)

sikeresen futtattam az exploit-ot amúgy sysresccd 1.5.5-ös live CD-vel, 2.6.32.14-std155-i386 kernel-lel.

ulimit -s unlimited
adduser guest
su guest
gcc *.c
./a.out

a végén ott figyelt a root prompt. gondolom hogy sikeres lehet, mert nem dobta az 'A' karaktereket stderr-re.

kieg.: ugyanez arch-on nem működött.

szerk.: azt hiszem, hogy csak a dos működhetett és az miatt omolhat össze az adott shell session a guest user-rel, és ezért kaphatom vissza a root login-t sysresccd alatt. számomra továbbra is nyitott a kérdés a privilégium szint emelés lehetőségének ellenőrzésére. a fenti kód csak a dos szemléltetésére elegendő ezek szerint?

értelmezésem szerint az "execv("/bin/sh", args);" hívással egy újabb shell-t nyitna, és innét már nem térne vissza a printf-re. csakhogy ez nem jön össze.

Ha nem menne, akkor valami ilyesmit írna ki: 


janos@virtual-void:~$/e.bin
execve failed
janos@virtual-void:~$ uname -a
Linux virtual-void 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 06:07:29 UTC 2010 i686 GNU/Linux
janos@virtual-void:~$

Mondjuk fura, hogy kiírja az A-betűket, mert ha a /bin/sh-nak adjuk paraméterként a sok A-t, hibaüzenetet is kellene látnod, hogy nem tudja megnyitni "A...A"-t.
Minden esetre, ha kiírja neked az A betűket, akkor sebezhető a géped.

-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 13.1 | 2.6.34.1-janos

Erre próbáltam reflektálni másutt, hogy 32 bites OS-en 32 bites programként nem kellene működnie, valamint olyan 64 bites gépen sem, ahol nincs 32 bites programok futtatására mód, mert nincsenek feltelepítve a 32 bites lib-ek.
Persze lehet, hogy más is meghúzódik a háttérben.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 13.1 | 2.6.34.1-janos

( egeresz | 2010. 08. 18., sze – 11:09 )

Elolvastam.

Leirom zanzaban.

Van egy regota letezo problema a linux kernel gondolkodasmodjaban. Ez alig zavart valakit, hiszen leginkabb alkalmazas eleses lehet belole, nem feltores. A hibaval csak olyan alkalmazas felett lehet atvenni a hatalmat, ami eleg nagy mertekig ugy is a tamado kontrollja alatt van.

Azonban a legtobb mai disztribucioban az X (a grafikat ado komponens) root-kent, teljes privilegizalt modban fut. Az X eleg bonyolult ahoz, hogy a felhasznalo igen nagy kontrolt kapjon hozza. A fenti kernel koncepciohiba es az X szokasos root futtatasa egyutt kombinalva egy szinte minden disztribucioban mukodo user -> root jogosultsagszint novelest tesz lehetove a tamado szamara.

A hiba x86_32 architekturan probalva, kiaknazhato.
A hiba x86_64 architekturan probalva, kiaknazhato.
Mas architekturan varhatoan kiaknazhato (nem probalva).

A kernel koncepciohiba reszletesebb leirasa
A programok tobb adatteruletet hasznalhatnak adataik tarolasara, az egyik neve stack. (azonkivul heap, shm) A stack felulrol lefele novekszik. A kernel koncepciohibaja az, hogy lehetseges egy olyan shared memory szegmenst allokalni, amibe bele tud noni (felulrol) a stack. Amennyiben a ket adatterulet osszeer, ugy lehetoseg van a shared memory szegmensen keresztul modositani a stack tartalmat. A stack tartalmanak megfelelo modositasaval tetszoleges kod futtathato az adott program kornyezeteben.
Mi kell hozza? Egy program, ami elegge kezbentarthato (shared memory letrehozasra kell kenyszeriteni, valamint a stack hasznalatat is ki kell kenyszeriteni)
Mit ad: programfuttatast a fenti tulajdonsagu program kornyezeteben

A hiba kihasznalasa az X segitsegevel
Az X egy nagyon bonyolult rendszer. Lehetoseget ad a felhasznalonak shared memory allokalasra, valamint rekurziv (stackzabalo) fuggvenyek hivasara is. Ez lehetoseget ad a tamadonak arra, hogy a fenti hibaval e ket teruletet osszeeressze, es az X stackjat modositva az X futtato user neveben futtasson barmit. A problema az, hogy az X az root neveben fut a legtobb disztribucioban.

(ez a bejegyzes nem a velemenyemet tukrozi, csak a megadott pdf magyarazo tomoritese)

Igen.

Ugy tunik (es ez a sajat velemeny) hogy van egy biztonsagtechnikaval foglalkozo szubkultura, ahonnan 'nem jonnek ki' (nem lesznek altalanosan ismertek) az kideritett hibak. Az Invisible Things Lab bedolgozta magat ide, es a szubkultura altal regota ismert (tipikusan 4-5 eves) sebezhetosegekbol publikal egy cirkalmasat. Persze keves hozzaadott ertekkel.
Ez nem azt jelenti, hogy ne dolgoznanak az Invisible T.L. -nel nalamnal jobb, esetleg sokkal jobb biztonsagi szakemberek, mert dolgozhatnak epp. Csak eppen nem a sajat munkajuk gyomolcseit elvezik, hanem egy kicsit vitetik magukat.

Az megint egy masik szal, hogy mi a velemenyem arrol, hogy egy igen jelentos agyi osszkapacitasi kozosseg nem publikalja a megtalalt hibakat. Kicsit cinkosan egyuttmukodnek a nagy cegekkel, akiket szinten nem zavar, ha nehany(szaz) rosszindulatu egyen torogeti az programjaikat, csak ne deruljon ki, ne legyen belole arcvesztes.

innentol mar hosszu lenne. Nem vagyok biztonsagtechnikai szakember, es nem veletlenul nem vagyok. Undorodom az "en tudom, es nem mondom meg, bibibeee" jellegu hozzaallastol, akar harombetus ceg csinalja, akar 12 eves kiskamasz, akar civil felnott.

"Undorodom az "en tudom, es nem mondom meg, bibibeee" jellegu hozzaallastol"

Azért nem ilyen egyszerű az ügy szerintem. Valszeg van ilyen is, de azért az is bejátszhat amikor közlik az emberrel, hogy "túl sokat aggódik az ember a biztonságért", vagy a fejlesztő cég azt mondja, hogy amit találtál, az nem is security hiba, esetleg beismerik a hibát, de azt mondják, hogy nem lehet kihasználni, esetleg nem is válaszolnak, hiába jelentik a hibát.. Nagyon sok minden közbejátszhat, ami miatt azt mondja valaki, hogy "baxátok meg, akkor fulladjatok meg". Innentől meg már külön szál, hogy open-disclosure, exploit fejlesztés, vagy mi lesz belőle.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Na most oké, szubkultúra ide vagy oda.

Most a csaj publikált egy nagy kupac, gőzölgőt. (cikket úgy értem. :D) Hatalmas körívekben beszélt a stack overflow típusú támadásokról érintve az X-et meg egy-két dolgot.

Na most sztem valakinek fel kellene nyitnia a szemét, hogy mióta a homo sapiens elkezdett programozni Logo-ban, azóta vannak stack overflow típusú hibákon alapuló támadások rendszerek ellen.

Kódot nem virított, és Linus aug 13-án pusholta a patchet.

--
GPLv3-as hozzászólás.

a fő bajom az ezzel a cikkel, hogy van egy kernel bug. az én eszem szerint a kernelt kell megpatkolni ahhoz, hogy a bug megjavuljon. ő meg mindenféle kacatot reklámoz, hogyha felteszed az ő virtualizációs agymenését, akkor ugyan a bug marad, de nem lehet majd kihasználni vagy valami ilyesmi.

Van igazsag a virtualizacios agymenesben.
Feleheto, hogy ilyen hibabol a kernelben, barmiben van meg masfelezer. Ha talalunk egy megoldast, ami a hiba kijavitasa nelkul lehtetlenne teszi a hiba kiaknazasat, akkor egycsapasra masfelezer hibat javitottunk.

Es van hazugsag abban, amit allit, hiszen a virtualizacios agymenes az csak bizonyos hibak ellen ved, azon az aron, hogy behoz nehany ujabb potencialis hibat. Volt pl a VMware-ben, hogy hibasan emulalta a CPU-t, es deklaraltan ki lehetett jutni a VM userebol a VM kernelebe. Azt sem tartjuk lehetetlennek, hogy a VM kernelbol a fizikai kernelbe ki lehessen jutni. MInt ahogy ring0 -> ring-2 kijutast is lattunk mar procihibabol kifolyoloag.

( LGee | 2010. 08. 18., sze – 11:43 )

"profitért és a mulatság kedvéért"

( w4rp v | 2010. 08. 18., sze – 13:50 )

rootkent futo X ami eleve vicc mar nagyon reg ota

( trey | 2010. 08. 18., sze – 20:57 )

"In an email to The H, Joanna Rutowska clarifies that Spengler's exploit targets "some unrelated vulnerability" and her reference to it was in relation to guesses made by Spengler noted in the source code comments."

A fentiek szerint Spengler kódjának nincs köze ehhez a sebezhetőséghez.

--
trey @ gépház

( totya | 2010. 08. 19., cs – 15:05 )

A H-online frissítette a cikkét:

Update - As Marcus Meissner from the SUSE security team explained to heise Security, SUSE maintainer Andrea Arcangeli provided a fix for the problem in September 2004, but for unknown reasons this fix was not included in the Linux kernel. SUSE itself has the fix and SUSE Linux Enterprise 9, 10 and 11 as well as openSUSE 11.1 through 11.3 do not exhibit this vulnerability.

Vagyis a Heise Online értesülései szerint már 2004-ben készített egy javítást az ominózus problémára a SUSE egyik fejlesztője. Nem került be a javítás a kernel-be. A SUSE (Novell) a SLES9, SLES10, SLES11 és openSUSE 11.1-11.3 verziókban szállítja is a kernel fixet. Hmmmm. Aranyos...

A forrás itt található.