Hívásokat rögzítő és távoli szerverre továbbító Android malware bukkant fel

A Total Defense egyik blogbejegyzése szerint olyan Android malware bukkant fel nemrég, amely telepítés után rögzíti a telefonhívásokat és a hozzájuk kapcsolódó információkat, majd azokat megpróbálja egy távoli szerverre továbbítani (noha a kódban levő elgépelés miatt a folyamat ezen funkciója jelenleg nem működik). A beszélgetéseket "amr" formátumba rögzíti. Természetesen a telepítéskor a felhasználó tájékoztatást kap arról, hogy a szoftver milyen funkciókhoz kíván a telefonkészüléken hozzáférni:

0

A "record audio", "intercept outgoing calls", "read phone state and identity" figyelmeztető a security-aware emberek számára, de az átlagemberek nagy része ezeket a figyelmeztetéseket figyelmen kívül hagyja.

A biztonsági cég újfent kiemeli, hogy ez az év a 'mobil malware'-ek éve. Ezért mindenkinek érdemes fokozott körültekintéssel, odafigyeléssel, az alapvető biztonsági irányelveket szem előtt tartva böngésznie, illetve beszereznie, telepítenie és futtatnia - főleg a bizonytalan forrásból származó - mobil alkalmazásait.

Az eredeti blogbejegyzés szerzője elmondta, hogy a trójait nem a szabadban kapták el, hanem ún. "malware gyűjtemény csatornán" keresztül jutott el hozzájuk.

Mindenesetre az elkerülhetetlen, hogy az Android felhasználók - akik egy friss felmérés szerint most sokkal valószínűbb, hogy malware áldozatai lesznek mint mondjuk fél évvel ezelőtt - nagyobb odafigyeléssel használják mobilkészülékeiket.

További részletek itt és itt.

Hozzászólások

Az Android jóvoltából az eddigi windowsos ökoszisztémában tevékenykedő vírusirtó-gyártó cégek továbbélése biztosított. :)

--
Steve Jobsot nagyra becsülöm üzletemberként és sajnálom, mint magánembert.
Viszont mint vallásalapítót, ki nem állhatom.

azért az hozzátartozik, hogy ez gyári romok esetén nem fog működni, csak kínában (ott is a defy kínai változatával és a kínának szánt xt701 készüléken) és dél-koreában a galaxy s egy változatával, azon is csak akkor, ha egy adott rom, vagy annál újabb van a készüléken.

aki rootolta a készülékét, annak még szükséges egy olyan kernelt telepítenie, ami tartalmazza a hívás rögzítéséhez szükséges patch-et (mivel alapvetően kernel szinten nem engedélyezett a hívások rögzítése), illetve ezen felül még adott radio fw is telepítve van a készülékére.
ezen kívül még maga az android főverzió is kritérium lehet, mert pl defy-n csak froyo-n működik (az általam ismert megoldás).

a cm kernelbe pont 1 hete került be a patch. az az előtti cm kernelekhez külön kellett patchelni.

vannak olyan custom romok, amikben alapértelmezetten van hívás rögzítés, na azokon ez hibátlanul működik.

mondjuk én erősen szoktam ajánlani az LBE privacy guard nevű kis appot, ami hasonló mint a win uac rendszere.
azaz ha egy program el akar érni egyes funkciókat, akkor arról bedob egy kis ablakot, ahol engedélyezhetjük vagy tilthatjuk a hozzáférést (mondjuk google maps esetén a helymeghatározást engedélyezhetjük de a kimenő hívásokat tilthatjuk, stb).
ha egy program hívást kezdeményez, akkor azt is mutatja, hogy pontosan milyen számot hívna, ha sms-t küldene, akkor mely számra mit küldene.
persze egy dialer vagy sms app esetén ezeket alapvető szükséglet engedélyezni és ha mondjuk pont ezen appok küldenének vagy hívnának csúúúúnya számokat, akkor már nem fogja megkülönböztetni. max akkor, ha minden egyes ilyen kérelemnél jóvá akarjuk hagyni - vagy tiltani - a hozzáférést, de szerintem a felhasználók zöme a "dont ask again" opció kipipálásával ad engedélyt, vagy állít be tiltást.

aki ettől függően rettegne, annak ajánlom még, hogy használjon bt fülest. az azon át történő kommunikációt ilyen módon rögzíteni nem lehet.

többek között ezért nincs még olyan üzenetrögzítő alkalmazás, ami a telefonra mentené a hangüzeneteket. nagyon kevés készüléken működik, illetve kevesen bütykölik olyan formában a készüléküket, hogy ez működhessen.

ezektől függetlenül a google-nek bőven lenne min dolgozni.

pedig mennyien szeretnének ilyen appot LEGAL használni! tudtok ilyet esetleg iphone/androidra?
(lehetőleg localba mentsen, de a távolra se katasztrófa)

Igen, jól érzed. Gyári és nem rootolt.
Közben rátaláltam a 2-Way Call Recorder-re, de itt (is) root kell az "Internal Recording"-hoz. Mondjuk ha ezzel a jelenlegivel csak annyi a gond, hogy root kell neki, akkor megoldom. Jó pár hónapja telepítettem fel és biztosan tudom, hogy azt írta, hogy nem fér hozzá a hívó hangjához csak a hangszórón keresztül.
Köszi az ötletet!

1 hülye dolog megint...

Szerintem biztonságban vagy ha:
- Csak gyári ROM-ot használsz
- Csak megbízható programokat telepítesz,
csak a marketről...

Minden további hülyeség a felhasználó hibája...

Vagy teljesen hibás a hozzá állásom és már dugig van a telóm vírussal ?

Ja, hallottam, hogy vannak eszetlen emberek. Hol itt a hír?

Mondjuk én meg hallottam, hogy remote exploittal sebezhető OS verziót telepítettek emberek (köztük én is) önhibájukon kívül telefonjukra azért, mert a vendor - immár második alkalommal - a "helyzet magaslatán" volt. Ettől még igaz, hogy a saját részünkről megteszünk mindent, ami tőlünk telhető.

--
trey @ gépház

Hát, ugye volt ez a Gyöngyöspatai telefonbotrány és nem értettem, hogyan lehetséges, hogy az ipse véletlenül felvette a telefonos fenyegetést.

A Marketen találtam egy VoiceRecorder nevű programot, ami az én hívásaimat felveszi és SD kártyán tárolja, internet hozzáférésre nincs joga, csak felvételre és tárolásra.

Sajnos a FAT file rendszeren nincsenek jogosultságok, így egy tök más alkalmazás simán képes lenne a VoiceRecorder fájlokat átnyomni a netre, szóval ez még nem tuti.

Jelenleg még vizsgálom, hogy hogyan lehetne biztonságosan rögzíteni automatikusan a hívásokat. Ha jó ötlet van, osszátok meg.

Sajnos a VoiceRecorder-t nem lehet úgy átállítani, hogy ne az SD kártyára nyomja a felvételeket, hanem mondjuk az SD-kártya második ext2 partíciójára.

Röviden:

egyik politikus felhívott egy polgármestert és megfenyegette telefonon, hogy ha nem ugrál úgy, ahogy ő fütyül, akkor leshet az állami pályázati pénzeknél.

Gondolom a polgármester telefonja automatikusan rögzített mindent és utána felkerült az egész a netre.

Ezek Magyarország politikusai: telefonon zsarolnak, gondolom 8 általános is nehezen lett meg nekik. Már évtizedek óta fel lehet venni a hívásokat.

Az egyetem alatt volt egy hasonló ökör, aki valamelyik tanszéket névtelen levélben elküldte a sunyiba. A hülyéje az egyetemi számítóközpontból küldte a névtelen e-mail-t, ennek következtében a levél elküldése után 10 perccel már a fegyelmi bizottságnál magyarázkodott.

Nem rúgták ki, de az összes szaktársam mondta, hogy aki informatikus és ekkora balfék, az kontárkodás végett ki kellett volna rúgni. :)

Ez a Google saját sara. Egy hagyományos linux disztribúciónál ilyen nem fordulhatna elő, mert:
1. a programcsomagok 99%-nak forráskódja nyílt,
2. ezeket a kódokat a csomag karbantartók (az esetek nagy részében) átnézik.
Semmi nem tökéletes, így a linux disztribúciók csomag/repó rendszere sem, mégis sokkal biztonságosabb mint a Market, ahol semmilyen rendszerszintű minőség-ellenőrzés nem létezik.

Bocs, simán előfordulhat.

Mondjuk rpmsearch-sel keresel egy rpm-et, ahol a disztribútort hírből sem ismered, telepíted, azt boldog vagy. Nagyságrendekkel értelmesebb a Google permissionkezelése, mint egy openSuSE rendszeré. Mert ott az RPM-ről financiád sincs, hogy mit tehet meg.

A Google értelmesen kitalálta a permission kezelést. Az, hogy te nem olvasod el, hogy mire adsz a programnak jogot, már a te bajod. A Google nem gondolkozhat helyetted.

Vagy ha telepíted a z4root programot, ami 'su'-t engedélyez minden alkalmazásnak, azután valaki egy "rm -rf *"-ot végrehajt a telefonodon, az sem a Google sara.

Sőt ha letöltöd a rageagainstthecage ARM binárist, végrehajtod és a telefon elkezd emelt díjas számokat hívogatni, az sem a Google sara.

Én úgy törtem fel a telefont, hogy a rageagainstthecage-et lefordítottam magamnak, miután meggyőződtem, hogy veszélytelen.

Rpm világban nem érhető el szinte bármilyen nyílt alkalmazás hivatalos repóból? Debian-Ubuntu világban ritkán kell külső csomagforrásokhoz nyúlni. Az ubuntu repók egyre inkább a launchpad.net-re koncentrálódnak, ahol hosszú távon nem lehet malwareket terjeszteni.

>>A Google értelmesen kitalálta a permission kezelést.
>>Az, hogy te nem olvasod el, hogy mire adsz a
>>programnak jogot, már a te bajod.
>>A Google nem gondolkozhat helyetted.

Most akkor döntsd el, az Android egy geek- rendszer akar lenni hozzáértő kocka felhasználói réteggel, úgy 1% részesedéssel
vagy
az átlagfelhasználót célozza meg??
Mert ezzel a >>te nem olvasod el, hogy mire adsz a programnak jogot, már a te bajod<< szöveggel csak elüldözni lehet az Android vásárlókat.

Szerintem a klasszikus linux disztribúciók maintainer rendszere jól működik 10-20 ezer csomagra. Persze sokkal több Android alkalmazás van már, de ha lenne ebből 20 ezer ellenőrzött alkalmazás, az sok androidos igényeit bőven kielégítené.
Nem az a helyes irány, hogy jöjjenek a vírus meg malware irtó alkalmazások Androidra. A windowst is ezért utálják a népek. Inkább be kellene vezetni egy minősítési rendszert. Ha nyíltabb lenne az Android fejlesztése mint a linux disztribúcióké, akkor a nyílt android progikhoz eleve lennének maintainerek közösségi alapon. A zárt alkalmazásoknál lehetne pénzt kérni a kód átnézéséért és ellenőrzéséért. Ez lehetne egyfajta minőségbiztosítás. Nem kellene kötelezővé tenni, de nyilván nagyobb lenne a bizalom a hivatalosan ellenőrzött android progik iránt.

1. Nem, az USA agyament szoftverszabadalmai miatt. Én openSuSE-t használok, annak a repo-ja meg nagyságrendekkel kisebb az Ubuntuénál, egy csomó értékes app-ot kiszedtek.

2. nem írja ki a Google villogó pirossal a kockázatokat, így szimplán csak 2 gombnyomásra települ minden.

A hiba nem az architektúrában van, hanem hogy nincs villogó piros ami figyelmeztet. A permission-öket néha én is elfelejtem elolvasni, úgy telepítek. A hiba a Market alkalmazásban van.

Ráadásul az, hogy nagyon sok program open source nem jelenti azt, hogy csak azt használ az ember. Én most vettem meg a 3. humble indie bundle-t, egy gram forráskód nincs benne, mégis teljes nyugalommal telepítettem fel a játékokat, mert... mégis mit tehetnék, álljak neki megtanulni némi disassembly-t, hogy egy kicsit kikapcsolódjak?

Google permission-kezelése:

1. a Google megengedi, hogy tetszőleges innen-onnan lebányászott programot telepíts
2. viszont az alkalmazás telepítésekor elő lehet írni, hogy az alkalmazás mit tehet meg és mit nem

Ha nincs a listán emeltdíjas számok hívása, akkor nem is fog tudni ilyen számokat hívni. A backend kivág téged, ha nincs jogod hozzá.

Amikor egy alkalmazást telepítesz, először olvasol:
- teljes internet?
- lekérheti az IMEI számát a telefonnak?
- az SD kártya olvasása?

Jó az nekem, ha az IMEI-t felnyomja a netre és az SD kártya komplett tartalmát vele együtt?

Először gondolkozol, utána telepítesz.

Hát, én bizony fel nem tenném ezt a programot, mert root-olt telefon kell hozzá.

Ha ez a program induláskor képes meghívni a "su"-t, akkor a securitynek onnantól lőttek. Ezt ugye tetszőleges másik program is megteheti, szóval tulajdonképpen már permission-ök sem kellenek neki, mindent megtehet, amit akar.

És mindemellett bíznod kell, hogy az "LBE privacy guard" nem egy trójai és nem él vissza a jogosultságaival. Ráadásul nem is opensource.

Jó, akkor elmagyarázom lassabban: a real-time permission control lehetősége hiányzik az androidból. Szerintem még az is jobb, ha egy 3rd party, closed source (mondjuk ebben nem látok semmi rosszat), rootolást igénylő appot kell ehhez telepíteni, mint ha nincs ilyesmire lehetőség. Méghozzá azért, mert így 1 appban kell megbíznod, a többit már teljesen az ellenőrzésed alatt tarthatod, míg ha nem telepíted fel, minden feltelepített alkalmazásban meg kell bíznod (mivel más lehetőséged nincs). Azt az egy alkalmazást meg valamilyen tesztrendszeren szépen ki lehet tesztelni, hogy tényleg csak azt csinálja-e, amit ígér, nem muszáj a forráskódjában turkálni.

--
Don't be an Ubuntard!

Oké, hogyan root-olod a telefont? A su-t mindenki használhatja?

Indíts el egy terminált Androidban és írd be, hogy su. Rendszergazda leszel?
(sok root-olós alkalmazás ezt csinálja)

A kérdés azért fontos, mert Android alatt terminált indítani minden appnak joga van.

Utána már könnyű minden: /system/sbin/su root rm /data/app/*

Az sem magyarázat, hogy csak akkor engedélyezed a su-t, ha valami fontosat akarsz.

while true; do /system/sbin/su root rm /data/app/*; sleep 1; done

Minden másodpercben a háttérben futó app ellenőrzi, hogy most a su megy-e...

Jó, akkor elmagyarázom még lassabban: a real-time permission control lehetősége hiányzik az androidból. Ennek része az is, hogy real-time határozhatom meg, hogy melyik app indíthat su-t és melyik nem. Ha by default bármelyik app indíthat su-t, akkor az android jogosultságkezelése szar.

--
Don't be an Ubuntard!

Alapból az Androidban nincs su, csak az emulátorban. Az emulátor is csak a shell user-nek engedi meg a su-t, amit adb-n keresztül érsz el (telefon: USB debug mód, kábellel).

Amikor a z4root alkalmazást telepíted, ez felrak neked egy su-t. Ez az a su, amelyik minden alkalmazásnak megengedi, hogy rendszergazda legyen.

Ezért írtam, hogy ha root-olod a telefonod, onnantól kezdve a permission-ök lényegtelenek lesznek számodra. Felrak a z4root egy su-t, amit bárki bármikor meghívhat.

A su-t a telefonok azért nem engedik meg, mert pénzes appok is vannak, ahol a license fájlokat tárolják. Nincs lehetőséged arra, hogy egy fizetős alkalmazást lemásolj mindaddig, amíg nem vagy root. Ezért tiltja minden nagy cég és ezért kell exploit, hogy rendszergazda jogot szerezz.

Az egész hozzászólás arról szólt, hogy hiába tök jó program az LBE privacy guard, ha root-olt telefon kell hozzá (z4root), onnantól tök mindegy, mert mindenkinek mindent szabad.

Ha tévedek persze javítsatok ki, a z4root-ot nem raktam fel, mert kockázatosnak találtam. Életemben egyszer ki nem próbáltam, a rageagainstthecage exploitot is magamnak fordítottam.

Ennél lassabban már tényleg nem tudom elmagyarázni. Láttál már UAC-t? Amikor egy alkalmazás rendszergazdaként szeretne futni, vagy csak rendszergazdaként írható területre írni (stb.), akkor az UAC megkérdezi tőled, hogy te engedélyezed-e. Igen, minden alkalmazásnak joga van meghívni a megfelelő rendszerhívást, ami rendszergazda jogkörbe emeli (kb. su), de csak akkor kapja meg ténylegesen a jogosultságot, ha te is engedélyezed.

--
Don't be an Ubuntard!

A rootolt telefonod ezt megteszi? Mert akkor semmi gáz...

Nem mertem kipróbálni, mert nem én fordítottam, ismeretlen bináris meg rendszergazdiként nem megy fel a telefonomra.

Egy szó mint száz, letöltöm a z4root-ot és otthon emulátorból megnézem, hogy a su benne hogyan viselkedik. Érdemlegesen akkor lehet csak folytatni a vitát.

Most szólok, mielőtt csalódnál. Nem állítottam, hogy az LBE privacy guard ellenőrzi-e a su-hoz való hozzáféréseket. Csak annyit állítottam, hogy mivel az android jelenlegi jogosultságkezelési rendszere szar (nem tudok rá jobb szót), ezért egészen addig, amíg nem telepíted "az LBE privacy guard-ot (vagy egy ahhoz hasonló appot)", biztosan nem vagy biztonságban. Persze az alkalmazás minőségétől függően lehet, hogy a telepítés után se leszel teljes biztonságban, de az elvi lehetőség megvan rá.

--
Don't be an Ubuntard!

Nem arról beszéltem, hogy az LBE privacy guard rossz egészen idáig.

A root-olásról beszéltem és azt állítottam, hogy ha a z4root-ot felrakod, akkor mindenkinek mindent lehet azután. Márpedig az LBE igényli a z4root-ot.

Amit emulátoron ki fogok próbálni, hogy a z4root valóban biztonsági rés-e. Ha az, akkor hatalmas.

Mármint lehet az LBE privacy guard a legjobb program a világon, amíg a z4root, az egyik szükséges komponense ingyen osztja a permission-öket mindenkinek. Ezt kell megvizsgálnom, onnantól lehet érdemben folytatni a vitát.

Még mindig nem érted. Egyrészt én nem programokról, hanem technikákról beszélek. A z4root nyújt egy szolgáltatást, amire egyrészt a LBE privacy guard-nak szüksége van, másrészt viszont önmagában minden alkalmazás használhatja, akkor is, ha a többi alkalmazásnak nem szabadna használnia. Ugyanakkor az LBE privacy guard is nyújt egy szolgáltatást, amivel szabályozható, hogy különböző szolgáltatásokhoz melyik alkalmazás férhet hozzá, és melyik nem. Elvileg, ez utóbbi (az előbbi szolgáltatását igénybe véve) képes arra is, hogy ezt a szolgáltatást más alkalmazások számára elérhetetlenné tegye.

"Amit emulátoron ki fogok próbálni, hogy a z4root valóban biztonsági rés-e. Ha az, akkor hatalmas."

Igen, önmagában az.

"Mármint lehet az LBE privacy guard a legjobb program a világon, amíg a z4root, az egyik szükséges komponense ingyen osztja a permission-öket mindenkinek. Ezt kell megvizsgálnom, onnantól lehet érdemben folytatni a vitát."

A z4root ingyen osztja, de az LBE privacy guard ezt felülbírálhatja, elvileg. Gyakorlatilag attól függ, hogy a programot felkészítették-e erre.

Egy másik példa, hátha abból érthető. Adott egy rendszer, azon egy frissen létrehozott felhasználói fiók. A felhasználó meg akarja változtatni a fiók jelszavát. Ehhez be kell jelentkeznie, de ahhoz ismernie kell a fiók jelenlegi jelszavát. A legtöbb rendszeren ezt úgy szokták megoldani, hogy létrehozás után a fióknak van egy ideiglenes jelszava, amit természetesen ekkor nem csak a felhasználó ismerhet, hanem más is. Viszont a felhasználó be tud vele jelentkezni, meg tudja változtatni a jelszavát, és onnantól kezdve hiába ismerték mások is a jelszót, már nem tudnak belépni a felhasználó fiókjába. Most feleltesd meg az ideiglenes jelszót a z4root által nyújtott su-nak, az új jelszót az LBE privacy guard-nak.

--
Don't be an Ubuntard!

root függő, van olyan (gány) root megoldás, ami mindent rootként futtat. az gány meló. ellenben a normális root megoldások nem ezt teszik, ahhoz, hogy root jogot kapjon a felhasználónak kell engedélyezni.

marketről telepített root megoldások a gány kategóriába tartoznak.

Hogy tudjuk miről beszélünk: letöltöttem a z4root-ot emulátorra.

Honlapjuk nincs, marketen nincs fenn, mindenféle fájlmegosztó / warez oldalról lehet letölteni, telepíteni.

- Van egy Superuser.apk ezt kell elindítani és fut a háttérben.
- Amint beírod, hogy su, a superuser apk feldob egy ablakot, hogy elfogadod-e a su-t az alkalmazásra, vagy nem, ha igen, akkor továbbmegy.

Ez akár jó is lehetne, de:
- megbízható forrásból nem lehet letölteni
- nem lehet lefordítani magadnak és átnézni, hogy valóban ezt csinálja-e és nincs-e mögötte trójai
- nem állt módomban meggyőződni, hogy a TCP kapcsolat, amivel a su és a superuser apk beszélgetnek megbízható-e, vagy lehetőséget ad trükközésre

Amikor a su-t telepítettem, nem kellett kulcsot generálnom, szóval egy alkalmazás, amelyiknek kill joga van, kivághatja a superuser apk-t és átveheti a helyét, azzal, hogy lefoglalja a portot (legalábbis elsőre így látom), ezek után meghívja a su-t azt csókolom.

Nincs kedvem mélyebben elemezni a témát, ha látok forrást a z4root-ra akkor átnézem és ha elfogadható, akkor javasolhatom is, hogy mindenki fordítsom magának egyet. De forrás nélkül azt hiszem nincs miről beszélni.

hint: google
éppenséggel én épp unrevoked root-ot említettem, annak a forrását eléred ITT.
csak egy kérdés: mindennek átnyalod a forrását? mert az ok, hogy egy telefonon full control egy trójainak nem egészséges, de azért ne legyünk már ennyire paranoidok. ennyi erővel csodálom, hogy bármit telepítesz az internetről (vagy akár épp a marketról).

A telefonom tud emeltdíjas számokat hívni a számítógép nem.
Éppen ezért igen, átfutom a forrást, vagy megbízható helyről töltöm le (Google).

Ha lesz időm eljátszom az unrevoked roottal is.

A z4root minthogy nem generált kulcsot, így gondolom a su vakon kommunikál egy porttal, amit bárki lefoglalhat, nem csak a superuser apk. Max 10 perc feltörni.

speciel nekem nagyobb gond lenne, ha a gépemen nyelnék be valamit és a jelszavaim eltulajdonításra kerülnének.
kinek ez, kinek az.
idestova 2 éve használok rootolt telót, nem volt még bajom. persze lehet. de általában úgy vagyok ezzel, hogy ami xda-n jó ideje fent van, azzal nagy baj nem lehet. persze biztos, hogy vannak kivételek, általános nagy igazság nincs :)
szíved joga tartani tőle, ezzel nincs baj.

Z4ROOT források:

su.c -> http://code.google.com/p/superuser/source/browse/trunk/su/su.c
http://code.google.com/p/z4root/source/checkout

Működése:

1. rendszergazda módba lép SUID miatt
2. a superuser APK könyvtárában lévő SQLite adatbázist beolvassa és ellenőrzi, hogy engedélyezett-e a processzre a su
3. amennyiben nem engedélyezett, elindítja a superuser apk activity-t, a telefon feldobja, hogy su-zni kellene
4. 10 másodpercig ellenőrzi, hogy engedélyezve lett-e a su, ha letelik az idő, kiszáll
5. ha engedélyezve lett, elindítja a terminált rendszergazda módban

Ez így biztonságosnak tűnik. Lehet, hogy fordítok én is magamnak egyet és felrakom.

ha kellően elterjedt és átnyalt, tesztelt root folyamatot alkalmazol, nagy bajod nem lehet (ettől persze az ördög még nem alszik).
a legnagyobb odafigyelést az alkalmazások jelentik. ami a nem root appokra szintén igaz.

az LBE-t meg ajánlom, bár annak a forrása szerintem zárt (már ha át szeretnéd nézni). nem tudom, hogy mióta használom, de bajom még nem volt belőle, csak előnyöm.

amúgy a legtöbb esetben azért nincs kint a root megoldások forrása, mert így a gyártók könnyebben zárni tudnák az adott exploit-ot kihasználó root folyamatot.
sok root alkalmazás leírásában benne is van, hogy jogos kérés esetén elküldik.

A gyártóknak kötelessége az exploit-ot bezárni. Csak a munkájukat végzik, amikor foltoznak.

Elég furcsa ez a szituáció:
- aki alkalmazást fejleszt, nem akarja, hogy a felhasználó rendszergazda legyen a telefonon, mert kártyafüggetleníti a telefonját, illegálisan lemásol fizetős alkalmazásokat, egyszóval lehetősége lesz bűncselekményt elkövetni rendszergazdaként
- én megvettem a telefonom, van rajta egy Linux, miért ne vezérelhetném a rendszert a saját felelősségemre? Enyém, miért akarja az operátor meggátolni, hogy a saját igényeimhez alakítsam?

Kicsit arra hasonlít, mintha betiltanánk az összes autót, mert ittasan lehet vele vezetni, ami bűncselekmény. Csak buszvezető vezethet, mert őbennük megbízunk...

Superuser.apk, legfrissebb verzió forrása (csontváz ikonos):

https://github.com/ChainsDD/su-binary/blob/master/su.c
https://github.com/ChainsDD/su-binary/blob/master/activity.cpp

Az sqlite3-as marháskodást TCP-re cserélték az új változatban.

Az sqlite3 biztonságos volt (ami a google oldalán van fenn), mert csak az adott alkalmazás és a rendszergazda (su) látta.

Pontosan nem értem, hogy az új változatban mi történik, de egyenlőre nem látok arra garanciát, hogy egy szemfüles program ne tudna a su kérésére azonnal válaszolni, megelőzve a superuser apk-t.

Egy TCP portra az "ALLOW" visszaküldése igazán nem nagy ügy. Szóval, ha valakinek van affinitása a biztonsági dolgokhoz, igazán megnézhetné. Nekem nagyon ködös az egész.

az ugye megvan, hogy a normál root esetén (nem gány) minden ami su-val futna, jogot is kell, hogy kapjon. amiről előzőleg kapsz egy szép pop up-ot, hogy engedélyezed, vagy sem.
terminál esetén is (unrevoked root) ha su-t kérek, akkor kapok egy kis ablakot, miszerint a terminal emulator root jogot kér.

Azért azt tegyük hozzá, hogy a rootolt telefon nem jelenti azt, hogy alapból minden progi által hozzáférhető su van a rendszeren. Van egy superuser alkalmazás, ami az user pofájába tol egy dialogot, ha egy nem engedélyezett app akar su-t indítani, és eldöntheted, hogy egyszer engedélyezed, vagy fehér- illetve feketelistázod a progit.

"ezeket a kódokat a csomag karbantartók (az esetek nagy részében) átnézik."

mint huzamosabb ideig tevekenykedo csomagkarbantarto kijelenthetem, hogy soha nem neztem at egyet sem es nem is ismerek senkit aki ezt megtette volna (lefordulashoz szukseges taknyolason kivul)

--
NetBSD - Simplicity is prerequisite for reliability

Nincs szoros összefüggés a kettő között. Ha ugyanúgy sok felhasználója lenne a linux disztróknak mint az Androidnak és ezért célzottan lőnének rájuk rendszeresen a malware üzemek, akkor sem menne át annyi káros alkalmazás a maintainer szűrőn, mint amennyi bejut a szűrő nélkül működő Marketre.

De van összefüggés. Több alkalmazás->több felhasználó->több "malware".
Egyébként azt írtad, hogy "hagyományos linux disztribúciónál ilyen nem fordulhatna elő"
Erre írtam, hogy hamis biztonságérzet. Igenis előfordulhat és elő is fordult már. Az semmit nem jelent, hogy egy alkalmazás nyílt forráskódú és a maintainerek "átnézik".