További biztonsági intézkedések az Android GPU-khoz

Közzétette Liz Prucka, Hamzeh Zawawy, Rishika Hooda, Android Security and Privacy Team A tavaly, a Google-ék Android Red Team együttműködött az Armmal, hogy egy részletes biztonsági elemzést végezzenek a Mali GPU-n, egy olyan komponensen, amely több milliárd Android-eszközben található világszerte. Ez a együttműködés egy jelentős lépés volt a GPU szoftverek és firmware rétegeinek meglévő gyengeségeinek proaktív azonosításában és kijavításában. Bár a egyedi hibák megtalálása és kijavítása elengedhetetlen, és a folyamat továbbra is zajlik, hogy teljesen megszüntessük őket, a támadás potenciális felületének korlátozása egy másik hatékony és gyakran gyorsabb módja a biztonság javításának. Ez a bejegyzés részletezi az Armmal való együttműködésünk, a GPU tovább megkötésére irányuló erőfeszítéseit. A növekvő veszély: Miért fontos a GPU biztonsága A grafikus feldolgozó egység (GPU) kritikus és vonzó cél lett a támadók számára, a komplexitása és a rendszerhez való jogosult hozzáférése miatt. Ez a veszély jelentős mértékben jelen: 2021 óta a legtöbb Android kernel driver alapú támadás a GPU-t célozta. Ezek a támadások elsősorban a User-Mode Driver (UMD) és a rendszerszintű Kernel-Mode Driver (KMD) közötti interfészt célozzák, ahol a rosszindulatú bemenetek a memóriakezelt hibákat okozhatják. Együttműködés az Armmal A célunk a GPU biztonságának növelése, a Mali GPU driver és a firmware ellenállását biztosítani. Együttműködtünk az Armmal a Mali driver elemzésében, amely körülbelül 45% -ban az Android eszközökben található. Ez a közös munka elengedhetetlen volt a driver támadás potenciális felületének megértéséhez és a biztonsági kockázatot jelentő területek azonosításához, de amelyek nem szükségesek a termeléshez. A megfelelő eszköz a feladathoz: Kötés a SELinux segítségével Az egyik kulcsfontosságú felfedezésünk az, hogy bizonyos GPU IOCTL-ekhez való hozzáférést korlátozhatjuk. Az IOCTL-ek a GPU kernel driver felhasználói be- és kimenetét, valamint a támadás potenciális felületét képezik. Ez a megközelítés épít az eddigi kernel-ös biztonsági erőfeszítésekre, például a 2016-os Protecting Android with More Linux Security című bejegyzésre. A Mali IOCTL-eket széles körben a következőképpen kategorizálhatjuk: Azonnali: Szükséges a normális működéshez. Mérés: Felhasználók által a profilozáshoz és hibakereséshez. Korlátozott: Nem szabad alkalmazásoknak a termelési környezetben használni. Ez magában foglalja azokat az IOCTL-eket, amelyek kizárólag a GPU fejlesztéshez vannak, valamint azokat az IOCTL-eket, amelyeket már nem használja a jelenlegi User-Mode Driver (UMD) verzió. Célunk, hogy korlátozzuk a korábbi és hibakereső IOCTL-ek használatát a termelési környezetben. Mérés az IOCTL-eket a profilozási eszközök monitorozására tervezték, és nem tervezték, hogy az alkalmazások közvetlenül használják. Ezért az hozzáférést korlátozzuk, vagy a shell vagy a “debuggable” jelzéssel ellátott alkalmazások. A termelési IOCTL-ek továbbra is elérhetőek a rendszeres alkalmazások számára. Egy szakaszos kiadás Az ez a megközelítés iteratív, és egy szakaszos kiadás, amely a Mali GPU-t használó eszközök számára. Így sikerült gondosan megfigyelni a valós használatot és adatokat gyűjteni, hogy validáljuk a szabályt, minimalizálva a legitim alkalmazások működését mielőtt a szélesebb körű alkalmazásba beépítjük: Opt-In Policy: Elindítottunk egy “opt-in” politikával. Új egy SELinux attribútumot, a “gpu_harden”, amely tiltja a mérés az IOCTL-eket. Ezután a rendszer alkalmazásaira, hogy teszteljük a hatást, kiválasztott rendszer alkalmazásokra alkalmaztuk. Az “allowxperm” szabályt használtuk az auditáláshoz, de nem a megtagadásra, és monitoráltuk a megtagadási naplókat, hogy biztosítsuk, hogy nincsenek hibák. Opt-Out Policy: Miután megbizottunk, hogy a megközelítésünk jó, elindítottuk a “opt-out” politikát. “gpu_debug” nevű egy domain-t hoztunk létre, amely lehetővé teszi a mérés az IOCTL-ek hozzáférését. Minden alkalmazást alapértelmezően biztonságosan szabályoztuk, de a fejlesztők kiválaszthatják, ha: A rendszeren gyököző eszközön futtatják. A “android:debuggable=true” attribútumot a alkalmazás manifest fájljában állítják be. A végleges kivételt az SELinux policy-ban kérik az alkalmazásuk esetében. Ez a megközelítés lehetővé tette, hogy a új biztonsági szabályzatot széles körben alkalmazzuk, miközben minimaliztuk az alkalmazások fejlesztői számára okozott hatást. A lépésről lépésre történő utasítások a Sepolicy-k hozzáadásához, hogy az Android Open Source Project dokumentációjában leírtak szerint segít a partnereinknek és az egész ökoszisztémának hasonló biztonsági intézkedéseket bevezetni. Végső következtetés a támadás potenciális felületének csökkentése hatékony megközelítés a biztonság megőrzésére, amely lehetővé teszi a felhasználók számára, hogy a meglévő, de még nem felfedezett, valamint a jövőben megjelenő veszélyeket is védd. Ez a erőfeszítés az Android-ról és az Android OEM-ekről szól, és szoros együttműködésben az Armmal. Az Android biztonsági csapat elkötelezett a szoros együttműködésben a szektorra vonatkozó partnerekkel, hogy a GPU-t biztonságosabbá tegyük. Köszönöm az Jeffrey Vander Stoepnek a “Protecting Android with More Linux Security” című bejegyzése ért.