r   e   k   l   a   m   a
r   e   k   l   a   m   a

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

Strona główna AktualnościBEZPIECZEŃSTWO

Bezpieczeństwo Androida zostało na dobre zakwestionowane po aferze z luką Stagefright, otwierającą drogę do ataku poprzez uzłośliwione obrazki, przesłane np. MMS-em. Była ona o tyle bolesna, że jak wiemy cykl aktualizacyjny tego mobilnego systemu jest słaby, jedynie najpopularniejsze i najlepsze urządzenia z Androidem dostają regularnie łatki bezpieczeństwa. Przy znanej nam architekturze Androida i wielości obsługiwanych przez niego urządzeń to się nie zmieni nigdy, dlatego to sam system musi uodpornić się na ewentualne luki w oprogramowaniu. W tę właśnie stronę idzie teraz Google, obiecując, że Android 7.0 „Nougat” będzie radykalnie bezpieczniejszy od swoich poprzedników.

Wzmacnianie drzwi do systemu…

Pierwsze informacje o tych dodatkowych zabezpieczeniach poznaliśmy już podczas tegorocznego Google I/O, kiedy to przedstawiono sprzętowy magazyn kluczy (notabene w niektórych implementacjach, w tym Qualcomma wcale nie taki bezpieczny, jak go Google przedstawiało), związany z nim mechanizm całodyskowego szyfrowania, zweryfikowany proces rozruchowy, uwierzytelnianie biometryczne, możliwość sprawdzenia stanu szyfrowania ruchu sieciowego oraz izolowanie pracy komponentów systemowych

To wszystko jednak zabezpieczenia wysokopoziomowe, które nie zablokują złośliwego oprogramowania, nie ograniczą skutków jego działania. Na szczęście Google na tym nie poprzestało. Pracujący nad bezpieczeństwem Androida zespół deweloperski ujawnił techniki, z jakich skorzystano do utwardzenia samego jądra systemowego i kluczowych bibliotek. Nikogo nie zdziwi chyba, że to rozwiązania możliwe tylko dzięki ciężkiej pracy deweloperów Linuksa i tych, którzy rozwijają dla tego systemu zestaw łatek Grsecurity.

r   e   k   l   a   m   a

…nie zastąpi fortyfikowania murów

Nougat przyniesie nam więc wyrafinowane mechanizmy ochrony pamięci, pozwalające odizolować ewentualne luki w jądrze od procesów działających w przestrzeni użytkownika. Po pierwsze, dodano możliwość oznaczenia izolowanych segmentów pamięci jako tylko do odczytu oraz jako bez prawa do uruchomienia. Dzięki temu obcy kod nie może zostać do nich zapisany, a tam gdzie możliwy jest zapis, stamtąd kodu nie można uruchomić. To rozwiązanie bazujące na funkcji KERNEXEC z łatek Grsecurity oraz opracowanego przez Qualcomma mechanizmu CONFIG_STRICT_MEMORY_RWX.

Po drugie, inspirując się funkcją UDEREF, ograniczono dostęp kernela do przestrzeni użytkownika, utrudniając w ten sposób ataki jeszcze bardziej, szczególnie jeśli pamięć została podzielona już na izolowane segmenty – napastnikowi do wykorzystania zostaje bardzo 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łnienia bufora.

Drugi rodzaj wprowadzonych zabezpieczeń wiąże się ze zmniejszaniem powierzchni ataku i ograniczaniem eksponowanych użytkownikom funkcji systemowych, które mogłyby zostać wykorzystane przez malware. Przede wszystkim wyłączono domyślny dostęp do debuggera perf, wykorzystując łatkę Grsecurity CONFIG_GRKERNSEC_PERF_HARDEN. Deweloperzy będą mogli skorzystać z perf 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). Jedynie niewielka 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 ograniczy funkcjonowania oprogramowania.

W Androidzie 7.0 wprowadzono też mechanizm seccomp, będący czymś w rodzaju mechanizmu piaskownicy dla procesów uruchamianych z z 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. W nowej wersji systemu będzie działał na sprzęcie wszystkich producentów, jako domyślnie włączony mechanizm ochrony jądra. Co więcej, wykorzystano go do zabezpieczenia procesów przetwarzania mediów (mediaextractor i mediacodec), co ma zapewnić, że drugiego Stagefrighta już nie będzie.

Jak więc widzicie, Android staje się naprawdę twardym orzechem do zgryzienia, daleko bardziej zabezpieczonym, niż normalne desktopowe Linuksy. Nie ma w tym nic dziwnego – żaden twórca dystrybucji, nawet Canonical, nie sprawuje takiej kontroli nad komponentami systemowymi, nie może sobie też pozwolić na skrojenie całego systemu pod kątem zabezpieczeń kosztem funkcjonalności oprogramowania. Google może sobie swobodnie wybierać najlepsze niezależne linuksowe zabezpieczenia i wprowadzać je do Androida, dopasowując do nich całą resztę kontrolowanego przez siebie systemu. Można powiedzieć, że taki hybrydowy model rozwoju łączy to najlepsze z otwartego oprogramowania i oprogramowania zamkniętego, własnościowego.

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.