Ekstremalne zabezpieczenia Androida 7.0: kto na tym zdoła uruchomić malware?

Pierwsze informacje o tych dodatkowych zabezpieczeniach poznaliśmyjuż podczas tegorocznego Google I/O, kiedy to przedstawionosprzętowy magazyn kluczy (notabene w niektórych implementacjach, wtym Qualcomma wcale nie taki bezpieczny, jak go Googleprzedstawiało), związany z nim mechanizm całodyskowegoszyfrowania, zweryfikowany proces rozruchowy, uwierzytelnianiebiometryczne, możliwość sprawdzenia stanu szyfrowania ruchusieciowego oraz izolowanie pracy komponentów systemowych

To wszystko jednak zabezpieczenia wysokopoziomowe, które niezablokują złośliwego oprogramowania, nie ograniczą skutków jegodziałania. Na szczęście Google na tym nie poprzestało. Pracującynad bezpieczeństwem Androida zespół deweloperski ujawniłtechniki, z jakich skorzystano do utwardzenia samego jądrasystemowego i kluczowych bibliotek. Nikogo nie zdziwi chyba, że torozwiązania możliwe tylko dzięki ciężkiej pracy deweloperówLinuksa i tych, którzy rozwijają dla tego systemu zestaw łatekGrsecurity.

Nougat przyniesie nam więc wyrafinowane mechanizmy ochronypamięci, pozwalające odizolować ewentualne luki w jądrze odprocesów działających w przestrzeni użytkownika. Po pierwsze,dodano możliwość oznaczenia izolowanych segmentów pamięci jakotylko do odczytu oraz jako bez prawa do uruchomienia. Dzięki temuobcy kod nie może zostać do nich zapisany, a tam gdzie możliwyjest zapis, stamtąd kodu nie można uruchomić. To rozwiązaniebazujące na funkcji KERNEXEC z łatek Grsecurity oraz opracowanegoprzez Qualcomma mechanizmu CONFIG_STRICT_MEMORY_RWX.

Po drugie, inspirując się funkcją UDEREF, ograniczono dostępkernela do przestrzeni użytkownika, utrudniając w ten sposób atakijeszcze bardziej, szczególnie jeśli pamięć została podzielonajuż na izolowane segmenty – napastnikowi do wykorzystania zostajebardzo mało wykonywalnej pamięci kernela. Po trzecie wreszcie,wykorzystano nowy mechanizm kompilatora gcc 4.9, tzw.stack-protector-strong, który chroni przed błędami przepełnieniabufora.

Drugi rodzaj wprowadzonych zabezpieczeń wiąże się zezmniejszaniem powierzchni ataku i ograniczaniem eksponowanychużytkownikom funkcji systemowych, które mogłyby zostaćwykorzystane przez malware. Przede wszystkim wyłączono domyślnydostęp do debuggera perf, wykorzystując łatkę GrsecurityCONFIG_GRKERNSEC_PERF_HARDEN. Deweloperzy będą mogli skorzystać zperf teraz tylko zdalnie, poprzez powłokę Android Debug Bridge.

Znacząco ograniczono też dostęp aplikacji do wywołańsystemowych – poleceń ioctl (kontrola wejścia/wyjścia). Jedynieniewielka biała lista takich poleceń jest dostępna dla aplikacji.Ograniczono też dostęp do wywołań dla układów graficznych.Wszystko to, jak zapewniają deweloperzy, nie ograniczyfunkcjonowania oprogramowania.

W Androidzie 7.0 wprowadzono też mechanizm seccomp, będącyczymś w rodzaju mechanizmu piaskownicy dla procesów uruchamianych zz poziomu kernela. Uważni Czytelnicy zapewne pamiętają, że to jużbyło – seccomp-bpf zadebiutował już w Androidzie 5.0 Lollipop.Wtedy jednak działał on tylko w urządzeniach z serii Nexus. Wnowej wersji systemu będzie działał na sprzęcie wszystkichproducentów, jako domyślnie włączony mechanizm ochrony jądra. Cowięcej, wykorzystano go do zabezpieczenia procesów przetwarzaniamediów (mediaextractor i mediacodec), co ma zapewnić, że drugiegoStagefrighta już nie będzie.

Jak więc widzicie, Android staje się naprawdę twardym orzechemdo zgryzienia, daleko bardziej zabezpieczonym, niż normalnedesktopowe Linuksy. Nie ma w tym nic dziwnego – żaden twórcadystrybucji, nawet Canonical, nie sprawuje takiej kontroli nadkomponentami systemowymi, nie może sobie też pozwolić na skrojeniecałego systemu pod kątem zabezpieczeń kosztem funkcjonalnościoprogramowania. Google może sobie swobodnie wybierać najlepszeniezależne linuksowe zabezpieczenia i wprowadzać je do Androida,dopasowując do nich całą resztę kontrolowanego przez siebiesystemu. Można powiedzieć, że taki hybrydowy model rozwoju łączyto najlepsze z otwartego oprogramowania i oprogramowania zamkniętego,własnościowego.