Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

SE Android

2012.01.07. 18:44 | buherator | 18 komment

Az SE Linux projekt bejelentette az SE Android elérhetőségét, melynek célja, hogy az SELinux által megvalósított Mandatory Access Controlt Androidon is elérhetővé tegye.

Miért van erre szükség? Mindenek előtt fontosnak tartom megjegyezni, hogy az átlagos Android felhasználók biztonságára a legnagyobb veszélyt még mindig saját ostobaságuk jelenti, a legtöbb Marketen elérhető malware ugyanis egyszerűen elkéri a számára szükséges jogosultságokat, amit rendszerint meg is kap.

Ezen semmilyen szoftver nem fog tudni segíteni, de vannak tisztán technológiai problémák is, melyeken jó lenne mielőbb úrrá lenni:

Egyrészt sajnos a felhasználók mellett a fejlesztők sem mindig biztonságtudatosak. A Skype androidos kiadásában például mindenki számára olvasható fájlban kerültek eltárolásra a felhasználók adatai, így bármely más alkalmazás ki tudta olvasni azokat. Ha a fájlhozzáférések korlátozásának felelősségét az app fejlesztő helyett a felhasználó kezébe adjuk, egy jó alapértelmezett szabályrendszerrel az ilyen jellegű problémák elkerülhetővé válnak.

Mélyebben fekvő tervezési hiányosságokra világított rá Anthony Lineberry a DEFCON 18-on tartott előadásában. Ezeknek egy különösen figyelemre méltó halmaza épít az Andorid különböző IPC lehetőségeire, melyek kihasználásával például egy hálózati hozzáférést nem igénylő alkalmazás kinzézhet az internetre a böngészőn keresztül. Az alábbi videó demonstrálja a problémát egy távoli shell nyitásával:

A problémák harmadik osztályát a különböző kernel-sebezhetőségek jelentik, melyekkel szemben sajnos az SE Android sem tud teljes körű védelmet nyújtani, az alkalmazások és a rendszerkomponensek hatékonyabb elválasztásával viszont a támadók mozgástere jelentősen csökkenthető.

Ezek alapján az SE Android egyelőre a paranoiásabb kockák játékszere lehet, nem tartom azonban kizártnak, hogy a jövőben az apptelepítési kultúra illetve az Android Market szűrési mechanizmusainak fejlődésével - ami a szofisztikáltabb támadások megjelenését fogja eredményezni - szélesebb körben is szükségessé válhat a hardening megoldás telepítése, de hasonló megoldásra igény mutatkozhat vállalati környezetben is.

Címkék: android se android selinx

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

EQ · http://rycon.hu 2012.01.07. 19:10:35

én azt mondom h grsec-et kell rakni az SE mellé és meg van oldva :DD nyílván úgy h mindenki custom kernelként forgatja le otthon a gyártó sdk-jából!

buherator · http://buhera.blog.hu 2012.01.07. 20:06:40

@EQ: Miért ne adhatná a vállalat, az eszköz gyártója, vagy ne adj' Isten a Google az SE Androidot előtelepítve, ahogy az mondjuk a Red Hat + SELinux párossal már jó ideje működik?

EQ · http://rycon.hu 2012.01.07. 20:08:47

@buherator: kiadhatja, meg is teszik majd gondolom :) én a 3. próbáltam orvosolni egy mulatságosabb módon

buherator · http://buhera.blog.hu 2012.01.07. 20:16:36

@EQ: Ha belegondolsz, ahogy minden új kód, elméletileg a grsec maga is bevezethet új hibákat a kernelbe ;)

ghost_____ 2012.01.07. 21:35:29

Ennek akkor van egyedül értelme, ha a google vezeti be különben az egyébként is széttöredezett platformot még jobban széthuzza. Ha egyedi megoldás lesz belőle, akkor a vége az lenne, hogy minden programot minden gyártó minden telefonját tesztelni kellene.

Hunger 2012.01.07. 22:22:41

@buherator: az SELinux nem vezethet új hibákat a kernelbe? :)

buherator · http://buhera.blog.hu 2012.01.07. 22:29:48

@Hunger: Gondoltam, hogy ezt is kiemelem, de bíztam a kedves olvasók következtető képességében és a trollok jóindulatában. Utóbbi úgy látom hiba volt :P

Hunger 2012.01.07. 22:47:44

@buherator: akkor segítek: a különbség ott van a kettő között, hogy a grsec/PaX-ban található "kernel self-protection" megoldások jóesetben akár a saját biztonsági hibájuk kihasználását is megnehezítik vagy akár ellehetetlenítik, míg az SELinux-ban nincsenek ilyen jellegű prevenciós featúrák... ;)

buherator · http://buhera.blog.hu 2012.01.07. 23:15:11

@Hunger: Én egy elméleti lehetőségről írtam, az más kérdés, hogy a gyakorlatban X patch konkrétan hogyan befolyásolja a kód minőségét.

Hunger 2012.01.08. 02:51:44

@buherator: most néztem meg épp a Moneyball című filmet. Van benne egy kulcsmondat, amely valahogy így hangzik:

"aki nem a lefektetett új alapelvek szerint építkezik ezután, az egy dinoszaurusz".

Ezt gondolom én is. A PaX 12 éve lefektette az alapelveket (NX, ASLR, MPROTECT, etc.), amelyek közül néhányat azóta már átvettek a nagyok is. Akik viszont nem, azok menthetetlenül lemaradtak...

Ez a kernel self-protection téma ennek ellenére még mindig annyira új és előremutató, hogy sokan nem értik meg a lényegét. Elméletben az új kód új hibákat hozhat be a kernelbe valóban, viszont ebben az esetben az új kód egy magasabb szintre viszi a kernel önmaga biztonságát, a kontrollt és ezáltal az egész rendszer egyenszilárdságát azzal, hogy a továbbiakban a kernel sem tehet meg már bármit, az "ő mindenhatóságát" is korlátozza.

Érdemes elgondolkozni azon is, hogy ezt a userspaceben már úgyahogy máshol is bevezetett funkciót, mint az NX a kernelspaceben még mindig egyedül csak a PaX valósítja meg rendesen. Nincs sehol máshol a kernelben teljes W^X és annak korlátozása sincs máshol, hogy az adatlapokat csak úgy ne lehessen futtathatóvá tenni (kernelben való triviális ROP elleni védelem).

Az olyan megoldásokról, amelyek komplett hibaosztályok kihasználását és exploit technikák családját teszik lehetetlenné (mint pl. a REFCOUNT, USERCOPY és UDEREF) már nem is beszélve. Ezek több garanciát és próaktívan nagyobb biztonságot hoznak a rendszerbe, mint amennyi kockázatot rejtenek az új kódokkal behozott potenciális hibák.

buherator · http://buhera.blog.hu 2012.01.08. 12:45:23

@Hunger: Aludtam egyet és visszaolvastam a threadet. Az én állításom még mindig ez:

"minden új kód, elméletileg a grsec maga is bevezethet új hibákat a kernelbe"

Ha ezt objektÍv módon (pl. valamilyen metrikával, matematikailag) meg tudod cáfolni, vagy akár meg tudod mutatni, hogy egy ilyen cáfolat egyáltalán létezhet, akkor hajrá!

(Btw én magam is ellene vagyok annak, hogy az ilyen kérdéseket ennyire absztraháljuk, ilyen értelemben most az ördög ügyvédjét játszom)

A grsec/PaX áldásos hatásairól, jelentőségéről szóló eszmefuttatásaidnak pedig nagyon szívesen szentelek akár több önálló posztot, szerintem sokakat érdekelne.

Hunger 2012.01.08. 16:16:43

@buherator: Az állításodra a visszakérdezésemmel arra céloztam, hogy mire volt jó felhozni és kiemelni a grsec-ben lehetséges hibákat, míg ugyanezt selinux esetén nem tetted meg. Most vagy mindkettőnél elmész mellette, vagy kiemeled mindkettőnél, de _egyiket_a_másik_rovására_ kiemelni nem tűnik tárgyilagos véleménynek:

"a grsec maga is bevezethet új hibákat a kernelbe"

buherator · http://buhera.blog.hu 2012.01.08. 16:39:30

@Hunger: Én nem akartam a grsec rovására kiemelni semmit, a kommentemben EQ felvetésére reagáltam, bízva abban, hogy a következő logikai lépést mindenki maga megteszi. Bár én még mindig nem tudom belelátni ezt a felhangot a kommentembe, természetesen elképzelhető, hogy mások számára félreérthetően fogalmaztam, szóval álljon itt egy korrekció, biztos ami biztos:

Ahogy minden új kód, elméletileg az SELinux, de akár a grsec is bevezethet új hibákat a kernelbe, bár utóbbira nagyobb szorzóval lehet fogadni a bukméker irodákban (előbbire pedig volt már precedens).

Hunger 2012.01.08. 17:33:08

@buherator:

"Ahogy minden új kód, elméletileg az SELinux, de akár a grsec is bevezethet új hibákat a kernelbe"

Ezzel meg ugye nem mondtál lényegében semmit, gyakorlatilag "Captain Obvious" kategória. :)

"bár utóbbira nagyobb szorzóval lehet fogadni a bukméker irodákban"

Így már érdekesebb lehet. Viszont jogossá válna a kérdés, hogy "ezt objektÍv módon (pl. valamilyen metrikával, matematikailag)" alá tudod-e támasztani. ;D

Volt egyébként már biztonsági hiba a PaX-ban is, úgyhogy mindkettőnél van precedens. A kérdés mindig az, hogy mitől félünk, mi ellen akarunk védekezni és ennek érdekében mit vállalunk cserébe. Erre mondja az angol, hogy "trade-off".

Egyébként, ha kifordítjuk a dolgot, akkor akár mondhatnánk azt is, hogy a gyakorlatban teljesen mindegy hány új hibát hoz be a grsec/PaX a kernelbe egészen addig, amíg a kernelben önmagában a hibák száma nem nulla... ;)

Hunger 2012.01.09. 09:03:27

@buherator: Micsoda érvelés. :)

BTW

selinuxproject.org/page/SEAndroid

The Android build process requires allowing executable stacks.
setsebool allow_execstack=1

lulz

ace911 2012.01.09. 13:32:46

bocsi előre is, a nem túl szakmai, főleg nem a fenti vitával egyszintű hozzászólásért...

Az android-ot szerintem azzal lehetne menteni a user által kapott túl sok jogtól, hogy a jogosultsági igényeket valóban finoman szabályozhatóvá tennék, ill. a market-re kerülő programoknál ellenőriznék az igények jogosságát. Arra gondolok pl, hogy ha egy app írni akar, akkor ne sd full access-t akarjon, hanem pl. egy adott könyvtárba írhasson/olvashasson, ugyanez a netkapcsolatra, r/o címtár stb., stb. Ha valamiért tetszik egy program és jogosultság igénye van, akkor úgyis megkapja..(miért ne?) de legalább legyen meg fejlesztőkben is a biztonságutdatosság.. ill. ha az update után jönne a rosszaság az ellen legalább védhetne.. ami még előnyös lehetne a jogosultságtól függő funkcionalitás: ha nem adok pl. net és/vagy tárcsázó jogot, akkor a jegyzettömb legyen csak egy kis vacak lokális jegyzettömb..(amiért feltettem). Mindig bennem van a para, hogy a háttérben rezdülés nélkül bármi kitárcsáz a 0690...-re vagy aktiválja a netkapcsolatot amikor nem kellene..

synapse · http://www.synsecblog.com 2012.01.25. 21:01:51

ace911: ezt mar en is varom, teljesen jogos lenne.