Обзор Security новшеств Android 5.0

lollipop-review

new-feauters-android-5

ИСТОРИЧЕСКАЯ СПРАВКА

Для Google безопасность Android всегда играла далеко не последнюю роль. С самых первых версий Android был снабжен набором мощных средств защиты, среди которых можно отметить сандбоксинг приложений, систему разграничения полномочий, единый RPC-механизм для всех приложений и системы (Binder), язык программирования с проверкой границ буферов, контролируемую среду исполнения (dalvik) и, конечно же, повсеместное использование цифровых подписей (в том числе для исполняемого кода).

С каждым новым релизом механизмы безопасности дорабатывались и расширялись. Сначала Google занялась проблемами переполнения буфера и интегрировала наработки проекта OpenBSD в свою системную библиотеку Bionic (реализации функций dmalloc и calloc, Android 1.5), затем добавила поддержку бита No execute (NX) в 2.3, модифицировала систему сборки исходников для поддержки опций компилятора -fstack-protector и Wformat-security -Werror=format-security (защита от срыва стека и ошибок форматирования строк).

В версии 3.0 появилась встроенная функция шифрования всех пользовательских данных, основанная на проверенном годами и сотнями тысяч пользователей модуле Linux-ядра dm-crypt.

В Android 4.0 — так давно ожидаемый в корпоративном секторе API KeyChain, позволяющий устанавливать в систему и использовать сторонние цифровые сертификаты. В 4.1 была интегрирована функция шифрования установленных приложений (в первую очередь для защиты от копирования) и поддержка хардварного шифрования с помощью HAL-библиотеки keymaster (в зависимости от производи-

теля она может использовать тот или иной механизм шифрования, например M-Shield в чипах серии ОМАР4, на котором базировался Galaxy Nexus).

android-5-security

В феврале 2012 года Google переключилась на борьбу с вирусами и создала сервис онлайн-проверки приложений Bouncer, который запускал каждое публикуемое в Google Play приложение в эмуляторе и прогонял через многочисленные тесты, выявляя подозрительное поведение. В ноябре того же года был запущен сервис онлайн-проверки софта на вирусы прямо на устройстве пользователя. Изначально он работал только на 4.2, но к июлю 2013-го был интегрирован в пакет Google Services и стал доступен для всех устройств от 2.3 и выше. Начиная с апреля 2014-го проверка выполняется не только на этапе установки приложения, но и периодически для всего установленного софта. Для борьбы с SMS-троянами в Android 4.2 была интегрирована функция принудительного подтверждения отправки СМС на короткие номера.

Другим новшеством Android 4.2 стала интеграция в ОС подсистемы мандатного контроля доступа SELinux, которая изначально работала исключительно в «разрешающем режиме» (permissive mode), а в 4.4 была переведена в режим enforcing, но с использованием всего нескольких контекстов безопасности для низкоуровневых компонентов системы, что не слишком повышало защищенность. В качестве дополнительной меры в 4.3 был запрещен запуск SETUID -бинарников из каталога /system и задействована система полномчий (capabilities) ядра Linux для системных компонентов.

В целом за шесть лет развития Android Google проделала серьезную работу по улучшению общей безопасности системы, не скатившись при этом до уровня Apple с ее методом тотальной блокировки всего и вся. Операционка осталась гибкой, полностью подчиненной пользователю, но при этом достаточно безопасной для того, чтобы не возникало необходимости установки антивирусов и «включения режима параноика».

Тем не менее оказалось, что планы Google простираются гораздо дальше того, что уже сделано. Android 5.0 включает в себя столько security specific новшеств, что дальше, кажется, уже некуда. Но начнем с двух главных героев новостей: шифрования, которое заставляет девайсы тормозить после обновления до 5.0, и SELinux, который ломает root.

encrypt-data

ШИФРОВАНИЕ ПО УМОЛЧАНИЮ

 В очередной раз следуя нога в ногу за Apple (Джелбрейк для iOs 8 ), «корпорация добра» внедряет в Android функциональность, которая совсем недавно появилась в iOS. На этот раз речь идет о шифровании свежекупленного устройства — начиная с Lollipop (Google официально представила Android 5.0 Lollipop), все пользовательские настройки и данные в каталоге /data, а вместе с ними и внутренняя (эмулируемая) карта памяти будут шифроваться в режиме реального времени без ведома пользователя.

На практике это означает только то, что та самая функция шифрования из 3.0 теперь будет включена по умолчанию, но с двумя важными оговорками:

• для защиты ключа шифрования (Master Key) будет использован случайно сгенерированный ключ вместо ключа, полученного из PIN-кода экрана блокировки;

• этот случайный ключ (Key Encryption Key, КЕК) теперь может храниться в области памяти, защищенной с помощью реализованного в процессоре механизма Trusted Execution Environment (TЕЕ), такого, например, как Qualcomm Secure Execution Environment.

Другими словами, возможность расшифровки данных теперь доступна только одному небольшому компоненту ОС, а именно EIAL-библиотеке masterkey, работающей с ТЕЕ. Ни пользователь, ни другие части системы не смогут получить ключ шифрования в ее обход, так же как это не получится сделать человеку, который попытается снять дамп памяти напрямую с чипов NAND.

С другой стороны, шифрование никак не защитит устройство в том случае, если юзер не установит на экран блокировки PIN-код или не воспользуется функцией Smart Lock (о ней мы поговорим позже).

Поэтому заявления Google о том, что они сделали априори секьюрную операционку, которая не потребует лишних телодвижений от пользователя, как минимум лукавство.

Во всем остальном реализация шифрования осталась на прежнем уровне. Это поблочное шифрование раздела /data с помощью модуля dm-crypt и алгоритма AES-128 в режиме СВС с задействованием функции ESSIV:SHA256 для получения векторов инициализации (IV). Сам ключ шифрования защищен с помощью КЕК-ключа, который может быть или получен из PIN-кода с помощью прогонки через функцию script (www.tarsnap.com/scrvpt.html), или сгенерирован случайным образом и сохранен в ТЕЕ. При этом, если юзер купит смартфон на базе Android 5.0 с активированным по умолчанию шифрованием и затем установит PIN-код, последний также будет использован для генерации КЕК.

Функция script для получения ключа из PIN-кода используется начиная с Android 4.4 и заменяет применявшийся ранее алгоритм PBKDF2. Последний оказался уязвимым для подбора на GPU (6-значный цифровой PIN за 10 с, 6-значный знаковый — 4 ч с помощью hashcat), тогда как script, по заявлению создателей, увеличивает время подбора примерно в 20 ООО раз и вообще не подходит для GPU по причине высоких требований к памяти.

В заключение хочу сказать, что шифрование будет активировано только для устройств, изначально основанных на Android 5.0. Уже существующие девайсы, получившие обновление по воздуху, останутся незашифрованными.

SEANDROID

Технология SELinux, разработанная Агентством национальной безопасности США, уже давно используется во многих корпоративных и настольных дистрибутивах для защиты от самых разных видов атак. Одно из основных применений SELinux — это ограничение приложениям доступа к ресурсам ОС и данным других приложений. С помощью SELinux можно, например, сделать так, чтобы сервер Apache имел доступ только к определенным файлам и диапазону портов, не мог запускать бинарники помимо заранее оговоренных и имел ограниченный доступ к системным вызовам. По сути, SELinux запирает приложение в песочницу, серьезно ограничивая возможности того, кто сможет его взломать.

Вскоре после появления на свет Android разработчики SELinux начали проект SEAndroid (seandroid.bitbucket.org) с целью перенести систему в мобильную операционку и разработать ряд SELinux-правил для зашиты ее компонентов. Начиная с версии 4.2, наработки этого проекта входят в состав Android, но на первых порах (версия 4.2-4.3) используются исключительно для сбора информации о поведении компонентов системы (с целью последующего составления правил). В версии 4.4 Google перевела систему в активный режим, но с мягкими ограничениями для нескольких системных демонов (installd, netd, void и zygote). На полную же катушку SELinux заработал только в 5.0.

В Android 5.0 предусмотрено более 60 доменов SELinux (проще говоря — правил ограничений) почти для каждого системного компонента, начиная от первичного процесса init и заканчивая пользовательскими приложениями. На практике это означает, что многие векторы атак на Android, которые в прошлом использовались как самими юзерами для получения root, так и разного рода малварью, более не актуальны.

Так, уязвимость CVE-2011-1823, имевшая место во всех версиях Android до 2.3.4 и позволяющая вызвать memory corruption в демоне void, а далее передать управление шеллу с правами root (эксплойт Gingerbreak), не могла бы быть использована, будь она найдена в 5.0 — здесь, согласно правилам SELinux, void не имеет права запускать другие бинарники. То же самое справедливо и в отношении уязвимости CVE-2014-3100 в Android 4.3, позволяющей вызвать переполнение буфера в демоне keystore, и 70% других уязвимостей.

SELinux значительно снижает риск того, что устройством завладеют через эксплуатацию уязвимостей в низкоуровневых компонентах системы (многочисленных написанных на С и C++ демонах, исполняемых от имени root), но в то же время затрудняет получение root, так сказать, «для себя». Более того, отныне права root сами по себе не гарантируют полного контроля над системой, так как для SELinux нет разницы между обычным юзером и суперпользователем.

К счастью, это ограничение довольно легко обойти, если заставить приложения с поддержкой root выполнять привилегированные действия в неограниченном SELinux-контексте init. Такая функциональность реализована в SuperSU с версии 2.23 (посредством прокси, который запускается на раннем этапе загрузки, работает в контексте init и исполняет команды, принятые от бинарника su). Однако для его установки нужен кастомный recovery, который, в свою очередь, может быть установлен либо после «получения полноценного root» на устройстве (проблема курицы и яйца), либо после разблокировки загрузчика.

Также стоит иметь в виду, что SELinux не обязательно будет включен в твоем устройстве, тем более если речь идет о девайсе, который изначально поставлялся с более ранней версией Android.

ГОСТЕВОЙ РЕЖИМ

 Многопользовательский режим в Android появился еще в версии 4.2, но на протяжении развития четвертой ветки ОС оставался доступен только для планшетов (с возможностью включения на смартфоне с помощью хаков, например приложения 4.2 Multiple User Enabler). В 4.3 в его реализации появилась функция ограничения юзеров в полномочиях, что можно было использовать для запрета звонков, СМС и других возможностей девайса.

В Lollipop многопользовательский режим распространился также и на смартфоны, причем с несколькими весьма интересными доработками

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *