Google вероятно разделя нивата на корекцията за сигурност на Android за по-бързи актуализации на сигурността

Дълго време в ранната си история Android имаше репутацията на по-малко сигурен от iOS поради подхода на Apple към приложенията с „оградена градина“. Дали тази минала репутация е заслужена или не, не е нещо, в което ще се потопим, но е ясно, че Google е постигнал големи крачки в защитата на Android срещу уязвимости. Компанията не само предоставя нови функции за сигурност в най-новата версия на Android, Android P, но също така предоставят "корпоративна сигурност“ в най-новите им устройства благодарение на хардуерен модул за сигурност в Google Pixel 2/2 XL. Поддържането на устройството защитено също изисква непрекъснати актуализации, за да се коригират и всички най-нови заплахи, поради което Google има 

месечни бюлетини за сигурност за всички производители и доставчици на устройства да включат пачове срещу всички известни активни и потенциални уязвимости. Сега изглежда, че компанията може да прави промени в системата за корекция за сигурност на Android, като предоставя начин за разграничете нивото на корекция на рамката на Android и нивото на корекцията на доставчика заедно с буутлоудъра, ядрото и т.н. или за разделяне на нивата на корекцията за сигурност, така че производителите на оригинално оборудване да могат да предоставят чисти актуализации на рамката или по-добре да идентифицират на потребителя какво ниво на корекция изпълняват.

---

Месечни корекции за сигурност на Android - Учебник

Всички знаем, че корекциите за сигурност са важни, особено след като поредица от известни уязвимости бяха оповестени публично през втората половина на миналата година. The Уязвимост на BlueBorne атакува Bluetooth протокола и беше коригиран в Месечни корекции за септември 2017 г, КРАК е насочен към слабост в Wi-Fi WPA2 и е бил закърпен декември 2017 г, а уязвимостите на Spectre/Meltdown бяха коригирани предимно с Пачове за януари 2018 г. Поправянето на уязвимости като тези обикновено изисква сътрудничество с доставчик на хардуер (като Broadcom и Qualcomm), тъй като уязвимостта засяга хардуерен компонент като Wi-Fi или Bluetooth чип или ПРОЦЕСОР. От друга страна, има проблеми в операционната система Android като този toast съобщение overlay атака които изискват само актуализация на Android Framework, за да бъдат коригирани.

Всеки път, когато Google пусне ежемесечна корекция за сигурност, производителите на устройства са длъжни да коригират ВСИЧКИ уязвимости описани в бюлетина за сигурността за този месец, ако искат да кажат, че устройството им е защитено до тази месечна корекция ниво. Всеки месец има две нива на корекция за сигурност, които устройството може да изпълни: нивото на корекция на 1-во число от месеца или на 5-то число на месеца. Ако дадено устройство каже, че изпълнява ниво на корекция от 1-во число на месеца (напр. 1 април, а не 5 април), тогава това означава, че компилацията съдържа всички корекции на рамката И доставчика от изданието от последния месец плюс всички корекции на рамката от най-новия бюлетин за сигурност. От друга страна, ако дадено устройство каже, че изпълнява ниво на корекция от 5-то число на месеца (5 април, за пример), тогава това означава, че съдържа всички корекции на рамка и доставчик от миналия и този месец бюлетин. Ето таблица, която илюстрира основната разлика между нивата на месечните корекции:

Вероятно сте запознати колко лоша е ситуацията с корекцията за сигурност в екосистемата на Android. Графиката по-долу показва, че Google и Essential предоставят най-бързите месечни актуализации на корекцията за сигурност, докато други компании изостават. Може да отнеме месеци на OEM да въведе най-новите корекции на устройство, като например как OnePlus 5 и OnePlus 5T наскоро получи Априлска корекция за сигурност когато преди бяха на декемврийския пластир.

Състояние на корекцията за сигурност на Android към февруари 2018 г. Източник: @SecX13

Проблемът с предоставянето на актуализации на Android Security Patch не е непременно, че производителите на оригинално оборудване са мързеливи, тъй като понякога може да е извън техния контрол. Както споменахме по-рано, месечните актуализации на корекцията за сигурност често изискват сътрудничеството на хардуер доставчик, което може да причини забавяне, ако доставчикът не е в състояние да се справи с месечната корекция за сигурност бюлетини. За да се бори с това, изглежда, че Google може да започне да разделя нивото на корекцията за сигурност на Android Framework от нивото на корекцията на доставчика (и евентуално нивото на буутлоудъра и ядрото), така че в бъдеще производителите на оригинално оборудване да могат да осигурят чисто рамка за сигурност на Android актуализации.

---

По-бързи актуализации на корекцията за сигурност на Android за уязвимости на рамката?

Нов ангажирам се появи в Android Open Source Project (AOSP) gerrit, който намеква за „корекция за сигурност на доставчика prop", който ще бъде дефиниран във файловете Android.mk всеки път, когато се създава нова компилация за устройство създадено. Това свойство ще се нарича "ro.vendor.build.security_patch" и ще бъде аналогичен на "ro.build.version.security_patch“, който в момента съществува на всички устройства с Android, за да определи месечното ниво на корекцията за сигурност на Android.

Това ново свойство вместо това ще ни каже "VENDOR_SECURITY_PATCH" ниво на устройството, което може или не може да съответства на нивото на корекцията за сигурност на Android Framework. Например, дадено устройство може да работи с най-новите пачове на рамката от април 2018 г. заедно с пачовете на доставчика от февруари 2018 г. Чрез разграничаване между двете нива на корекция за сигурност е възможно Google да възнамерява да позволи на OEM производителите да доставят най-новите корекции за сигурност на Android OS, въпреки че доставчиците не са предоставили актуализирани корекции за тази месечна корекция ниво.

Алтернативно, Google може просто да покаже минимума от двете нива на корекция (евентуално наред с нивата на корекция на буутлоудъра и ядрото), за да се покаже по-точно на потребителя на каква корекция за сигурност е включено неговото устройство. Все още нямаме потвърждение за намерението зад тази корекция, но се надяваме скоро да разберем повече.

Най-малкото, това ще бъде полезно за тези от нас Проект TrebleОбщи образи на системата (GSI) и други персонализирани ROM, базирани на AOSP, тъй като често персонализираните ROM предоставят само актуализации на рамката, без да коригират целия доставчик, bootloader и корекции на ядрото, които са посочени в месечен бюлетин за сигурността, така че несъответствието предизвиква объркване сред потребителите, тъй като те мислят, че използват най-новите пачове, когато в действителност устройството им е само частично закърпено спрямо най-новата месечна защита бюлетин.