[Aktualizacja: załatano drugą lukę] Wykryto dwie krytyczne luki w zabezpieczeniach programu ładującego OnePlus 3/3T, jedna została załatana, a druga jest naprawiana

Zanim wejdziesz do wspaniałego świata rootowania Androida, niestandardowych ROM-ów, jąder i innych modyfikacji, musisz najpierw odblokować bootloader na swoim urządzeniu.

Na niektórych urządzeniach (zwłaszcza tych marki operatora) stanowi to problem, ponieważ użytkownicy muszą uporać się ze znaczącymi przeszkodami technicznymi, zanim będą mogli odblokować program ładujący. Inne urządzenia, takie jak telefony Huawei, wymagają zwrócenia się do producenta OEM o unikalny kod odblokowujący bootloader – niewielka bariera wejścia, ale niezbyt trudna. Jeszcze lepsze są telefony z serii Google Nexus/Pixel lub OnePlus, które wymagają jedynie zaznaczenia opcji w Ustawieniach programisty, a następnie wysłania kilku szybkie uruchamianie polecenia.

Ale niezależnie od tego, jak trudne może być odblokowanie programu ładującego, jedna rzecz zawsze pozostanie niezmienna: wymóg wyczyszczenia urządzenia po odblokowaniu. Odbywa się to z oczywistych względów bezpieczeństwa, ponieważ po odblokowaniu programu ładującego można łatwo wyodrębnić całą partycję danych. Złośliwy podmiot (posiadający wiedzę techniczną) może wykonać flashowanie niestandardowego odzyskiwania i wyodrębnić pełną kopię zapasową urządzenia, jeśli uzyska dostęp do Twoich danych. Dlatego odblokowanie programu ładującego jest uważane za zagrożenie bezpieczeństwa i dlatego po odblokowaniu urządzenie jest czyszczone. Zakładając, że wszystko pójdzie tak, jak powinno, zwykły użytkownik powinien być chroniony przed osobami atakującymi, które odblokują bootloader w celu ominięcia standardowych metod blokowania Androida. Nie wszystko jednak idzie zgodnie z planem.

Luka w zabezpieczeniach programu ładującego OnePlus 3/3T umożliwiająca odblokowanie

Pojawił się nowy zestaw luk właśnie ujawnione przez Roee Hay (@roeehay), z których pierwszy umożliwia odblokowanie bootloadera OnePlus 3/3T bez potwierdzenia użytkownika i bez konieczności przywracania ustawień fabrycznych. Ta luka jest oznaczona CVE-2017-5625, jest uważana za lukę o znaczeniu krytycznym i dotyczy wszystkich urządzeń OnePlus 3/3T działających pod kontrolą OxygenOS 3.2-4.0.1. Użytkownicy, którzy już dokonali aktualizacji do wersji przyrostowy OxygenOS 4.0.2 aktualizacja nie mają na to wpływu przez tę lukę, ponieważ pan Hay prywatnie ujawnił tę wadę OnePlus 23 stycznia aby mogli natychmiast załatać problem.

Usterka polega na wysłaniu zastrzeżonego, ukrytego polecenia fastboot: fastboot oem 4F500301. Wysłanie tego polecenia powoduje pominięcie stanu blokady programu ładującego użytkownika (nawet jeśli w Ustawieniach programisty nie włączono opcji „Zezwalaj na odblokowanie OEM”). Urządzenie nie podpowiada użytkownikowi ani nie wyczyści urządzenia tak, jak powinno - w rzeczywistości urządzenie nadal będzie raportować, że bootloader jest zablokowany! Kolejne polecenie fastboot, fastboot oem 4F500302, zresetuje niektóre ustawienia programu ładującego i może zostać użyte do zablokowania już odblokowanego urządzenia.

Pan Hay odkrył, że pierwsze polecenie fastboot ustawia coś, co nazwał „magiczna flaga", który zastępuje kontrolę określającą stan blokady programu ładującego podczas wykonywania polecenia flashowania lub kasowania.

// 'oem 4F500301' handler
intsub_918427F0()
{
 magicFlag_dword_91989C10 = 1;
 if ( dword_9198D804 != dword_9198D804 )
assert(1, dword_9198D804, dword_9198D804);
return sendOK((int)"", dword_9198D804);
}

// 'flash' handler
constchar *__fastcall sub_91847EEC(char *partitionName, int *a2, int a3)
{
char *pname; // r5@1
...
 pname = partitionName;
 v4 = a2;
 v5 = a3;
if ( returnTRUE1(partitionName, (int)a2) )
 {
 result = (constchar *)sub_918428F0(pname, v6);
 if ( (result || magicFlag_dword_91989C10)
 && ((result = (constchar *)sub_91842880(pname, v10)) != 0 || magicFlag_dword_91989C10) )
 {
 result = (constchar *)sub_918428F0(pname, v10);
 if ( !result || magicFlag_dword_91989C10 )
goto LABEL_7;
 v8 = dword_9198D804;
 if ( dword_9198D804 != dword_9198D804 )
goto LABEL_28;
 v11 = "Critical partition flashing is not allowed";
 }
else
 {
 v8 = dword_9198D804;
 if ( dword_9198D804 != dword_9198D804 )
goto LABEL_28;
 v11 = "Partition flashing is not allowed";
 }
return (constchar *)FAIL2((int)v11, v10);
 }
LABEL_7:
 ...
 if ( *v4 != 0xED26FF3A )
 {
 if ( *v4 == 0xCE1AD63C )
 cmd_flash_meta_img(pname, (unsigned int)v4, v5);
else
 cmd_flash_mmc_img(pname, (int)v4, v5);
goto LABEL_10;
 }
 v7 = v4;
 }
 cmd_flash_mmc_sparse_img(pname, (int)v7, v5);
 ...
 }

// 'erase' handler
int __fastcall sub_91847118(char *partitionName, int a2, int a3)
{
 ...
 v3 = partitionName;
 v4 = returnTRUE1(partitionName, a2);
 if ( !v4 )
 {
LABEL_7:
 ...
 if ( v4 )
 {
 if ( dword_9198D804 == dword_9198D804 )
return eraseParition(v3);
 }
 ...
 }
 v4 = sub_918428F0(v3, v5);
 if ( !v4 && !magicFlag_dword_91989C10 )
 {
 v6 = dword_9198D804;
 if ( dword_9198D804 == dword_9198D804 )
 {
 v7 = "Partition erase is not allowed";
return FAIL2((int)v7, v5);
 }
goto LABEL_23;
 }
 v4 = sub_91842880(v3, v5);
 if ( !v4 && !magicFlag_dword_91989C10 )
 {
 v6 = dword_9198D804;
 if ( dword_9198D804 == dword_9198D804 )
 {
 v7 = "Partition flashing is not allowed";
return FAIL2((int)v7, v5);
 }
LABEL_23:
assert(v4, v5, v6);
 }
 v4 = sub_918428F0(v3, v5);
 if ( !v4 || magicFlag_dword_91989C10 )
goto LABEL_7;
 v6 = dword_9198D804;
 ...
 v7 = "Critical partition erase is not allowed";
return FAIL2((int)v7, v5);
}

Można zastosować CVE-2017-5626 wykonaj kod jądra. Osoba atakująca może sflashować dowolny obraz rozruchowy. Jeśli jednak sflashują zmodyfikowany obraz rozruchowy, Verified Boot uruchomi się i ostrzeże użytkownika, że ​​wykryto modyfikację. Jednym ze sposobów obejścia tego problemu jest flashowanie starszego, niezmodyfikowanego obrazu rozruchowego — takiego, który zawiera starsze exploity, które zostały już załatane. Mimo to „ostrzeżenie”, które otrzymujesz, trwa tylko 5 sekund, po czym automatycznie się wyłącza i uruchamia się w stanie zweryfikowanego rozruchu, w którym kod atakującego będzie nadal wykonywany.

Pan Hay wspomina, że ​​lukę tę można wykorzystać w szkodliwy sposób na mnóstwo sposobów. Na przykład zmodyfikował obraz rozruchowy, aby ustawić tryb SELinux dozwalający a także automatycznie uwzględnia dostęp ADB podczas uruchamiania. Następnie, po wykorzystaniu tej luki do flashowania zmodyfikowanego obrazu rozruchowego, udało mu się uzyskać dostęp do pliku root, zanim użytkownik będzie mógł w ogóle wprowadzić swoje dane uwierzytelniające.

OnePlus3:/ # id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),
1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),
3003(inet),3006(net_bw_stats),3009(readproc) context=u: r: su: s0
OnePlus3:/ # getenforce
Permissive

Nie trzeba dodawać, że jest to dość poważne. Skradzione lub uszkodzone urządzenie, które Twoim zdaniem jest bezpieczne ze względu na stosowane przez Ciebie typowe środki bezpieczeństwa, może zostać całkowicie pokonane za pomocą tego exploita.

Luka w zabezpieczeniach SELinux OnePlus 3/3T

Druga luka, oznaczona jako CVE-2017-5624, ma wpływ wszystkie wersje OxygenOS i pozwala wyłącz dm-verity. Pan Hay ujawnił tę lukę zespołowi OnePlus Security w dniu 16 stycznia, ale należy zauważyć, że starszy członek XDA th3g1zniezależnie odkrył tę lukę NA 23 stycznia. Rozmawialiśmy z OnePlus, który to zrobił potwierdzili, że potwierdzili i naprawią tę drugą lukę w przyszłej aktualizacji.

Atak ten jest również dość prosty do wykonania. Wystarczy wydać jedno polecenie fastboot, aby wyłączyć (lub włączyć) dm-verity: fastboot oem disable dm-verity. Aby to włączyć, po prostu wydaj fastboot oem enable dm-verity. Poniżej pokazano procedurę obsługi tego polecenia, pobraną ze zrzutu programu ładującego.

// 'oem disable_dm_verity' handler
intsub_9183B8EC()
{
int v0; // r0@1
int v1; // r1@1
 dmVerity_dword_91960740 = 0;
 v0 = sub_91845E10("ANDROID-BOOT!");
 if ( dword_9198D804 != dword_9198D804 )
assert(v0, v1, dword_9198D804);
return sendOK((int)"", v1);
}

Wydanie tego polecenia ustawi flagę, którą pan Hay wywoła dmVerity, która jest używana przez program ładujący do wysyłania argumentu wiersza poleceń jądra, który może włączyć lub wyłączyć dm-verity.

Można to wykorzystać w połączeniu z pierwszą luką w celu wykonania wysoce uprzywilejowanego kodu na OnePlus 3/3T bez zgody użytkownika – i z dostępem do danych użytkownika. Na przykład pan Hay mógł zainstalować aplikację w /system/priv-app, co powoduje dodanie aplikacji do domeny priv-app. Umożliwia to złośliwej aplikacji dostęp do wysoce uprzywilejowanych funkcji urządzenia. Na poniższym filmie pan Hay pokazuje, jak obie te luki są wykorzystywane jednocześnie. Jak widać, po uruchomieniu urządzenia zbudowana przez niego aplikacja jest już preinstalowana.

Wnioski i notatki od OnePlus

Potencjalne nadużycia tych dwóch luk w zabezpieczeniach są przerażające. Gratulujemy panu Haya za prywatne i szybkie ujawnienie tych luk firmie OnePlus. Mimo to nie możemy powstrzymać się od zaniepokojenia, że ​​takie polecenia fastboot są dostępne na tych urządzeniach. Kiedy napisaliśmy poradnik, jak to zrobić odkryj ukryte polecenia fastboot, naszą intencją było poinformowanie użytkowników, że mogą istnieć pewne interesujące polecenia, których mogą użyć, aby poprawić swoje doświadczenia. Nigdy nie przypuszczaliśmy, że tak wysoce uprzywilejowane polecenia będą znajdować się w kodzie programu ładującego. Jeśli chodzi o "Dlaczego" te polecenia fastboot są zawarte w oprogramowaniu sprzętowym, otrzymaliśmy plik "bez komentarza." 

Na razie, jeśli nie aktualizowałeś swojego OnePlus 3/3T zaraz po wydaniu każdej kompilacji Oxygen OS, zalecamy zaktualizuj natychmiast. Aktualizacja do Oxygen OS 4.0.2 ochroni Cię przed pierwszą luką, ale będziemy musieli poczekać, aż OnePlus udostępnia aktualizację, która łata drugą lukę, zanim będziemy mogli stwierdzić, że jesteś przed nią całkowicie bezpieczny wykorzystuje. W przyszłości będziemy musieli zwracać uwagę na tego typu exploity.

Źródło: Roee Hay