Безопасность Android 8. Объясняем все новшества в механизмах защиты Oreo

Среди всех нововведений Android 8 особое место занимают три:

• Treble — новый модульный HAL (Hardware Abstraction Layer), который позволяет четко отделить от остальной части ОС низкоуровневый код ОС, зависящий от производителя смартфона и чипсета;
• система ограничений фонового исполнения приложений, которая должна помочь в борьбе со жрущими аккумулятор приложениями, запрещая их фоновое исполнение (если кратко: фоновый сервис может работать не дольше пяти минут, а приложение не будет разбужено или запущено от внешнего общесистемного события);
• Google Play Protect и другие нововведения, направленные на защиту пользователя от зловредных приложений, установленных как из Google Play, так и из сторонних источников.

С системой ограничений фонового исполнения все более или менее понятно, а о Treble, который в перспективе может кардинально улучшить ситуацию с обновлениями Android, мы уже писали. Но мы снова коснемся его в контексте обсуждения безопасности.

Google Play Protect

В 2012 году, практически одновременно с релизом Android 4.2, Google запустила облачный антивирус с неброским именем Verify Apps. Антивирус был встроен в сервисы Google Play, которые установлены почти на каждом Android-смартфоне как часть набора приложений Google, поэтому одно обновление сервисов Google Play быстро распространило антивирус на миллионы устройств без ведома пользователей.

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

Большинство юзеров об этом даже не подозревают и, наслушавшись историй о тотальной небезопасности Android, продолжают устанавливать на смартфоны сторонние антивирусы. В некоторых случаях это оказывается пустой тратой денег, в других оборачивается ложными срабатываниями, когда антивирус ругается на все, что может отправлять СМС, показывать рекламу в шторке или использовать оверлеи. В третьих (и это наиболее частый вариант) приводит к замедлению устройства и повышенному расходу заряда аккумулятора.

Чтобы решить эту проблему и показать, что на самом деле в смартфоне уже есть антивирус, Google придумала штуку под названием Google Play Protect. Это не что иное, как интерфейс, позволяющий оценить работу Verify Apps. В Android Oreo он доступен в разделе настроек «Безопасность», в более старых версиях — в разделе «Google → Безопасность». Ценность его невелика, но он позволяет быстро узнать, что с твоим смартфоном все в порядке и он регулярно проверяется (а если точнее — во время зарядки).

Google Play Protect

Вместе с новым интерфейсом Google вытащила наружу еще несколько индикаторов работы антивируса. Версия Play Store для Oreo показывает статус проверки приложения на его странице, а также выводит красивый зеленый щит с надписью «Все хорошо, парень, ты защищен» в списке установленных приложений.

Кроме того, разработчики сторонних приложений теперь имеют доступ к API Verify Apps, точнее к его маленькой частичке, которая позволяет проверить, есть ли на смартфоне вирусы, и запретить установку своего приложения, если это так.

Сторонние источники приложений

Процесс установки приложений из сторонних источников также слегка изменился. Теперь, чтобы установить приложение не из Play Store, нет необходимости активировать переключатель «Неизвестные источники» в разделе «Безопасность» в настройках. Вместо этого необходимо дать право устанавливать APK отдельно взятым приложениям.

Другими словами, если ты хочешь, чтобы Amazon Appstore и F-Droid могли устанавливать приложения, ты должен дать каждому из них такое право. И это действительно правильный механизм с одним «небольшим» минусом: чтобы установить Amazon Appstore, тебе нужен браузер, а это значит, что ему тоже необходимо дать право установки приложений. После этого весь механизм защиты летит к черту. Хотя, конечно, тебе все еще надо собственноручно подтверждать каждую установку приложения.

Treble

В Android 8 впервые появилась реализация инициативы Treble, которая стала самой крупной переработкой внутренних компонентов Android со времен Android 4.0. Смысл Treble заключается в разделении Android на две независимые части, одна из которых обеспечивает связь с железом (ядро Linux, драйверы и другие низкоуровневые компоненты ОС), а другая включает в себя саму операционную систему Android.

Логическое деление Android до Treble и после

В первую очередь Treble нацелен на решение проблемы обновлений и фрагментации. Производителям смартфонов теперь не нужно ждать, пока производители чипсета и другого оборудования соизволят выпустить драйверы и другие компоненты HAL для новой версии Android. Вместо этого они могут портировать Android на уже имеющуюся основу, и в теории он будет прекрасно работать.

Разработчики Android заявляют, что Treble также способен решить многие проблемы безопасности. Разработчики не только разделили ОС на две части, но и реорганизовали платформенно зависимые компоненты ОС. Каждый из них теперь работает в жестко изолированной песочнице и общается с компонентами ОС через типизированные каналы с проверкой полномочий (для этого в IPC-механизм Binder внесены соответствующие правки).

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

Защита от даунгрейда

Еще в Android 4.4 Google реализовала механизм Verified Boot, который проверяет целостность компонентов ОС на всех этапах загрузки смартфона и позволяет запретить загрузку, если обнаружится, что загрузчик, ядро или ОС были модифицированы. В следующих версиях Android механизм непрерывно совершенствовался, но в нем всегда была одна проблема — возможность сделать даунгрейд.

Даунгрейд опасен тем, что может быть использован для получения доступа к смартфону с помощью «возвращения старых багов». Допустим, человек украл телефон, понял, что он зашифрован, запаролен, а загрузчик заблокирован. Кастомную прошивку он установить не может (из-за несовпадения сертификата), но может откатить смартфон к старой версии Android, в которой был баг, позволяющий обойти блокировщик экрана (такой был в прошивке Samsung, например), и с его помощью получает доступ к содержимому.

Некоторые производители пытались защититься от даунгрейда своими методами. В Android 8 теперь есть официальная реализация этой защиты. Но она отключается при разблокировке загрузчика штатными средствами.

Другие статьи в выпуске:

Xakep #224. Доступ разрешен

• Содержание выпуска
• Подписка на «Хакер»-60%

Фильтр seccomp для приложений

Seccomp — это технология ядра Linux, которая позволяет ограничить список доступных приложению (и в перспективе опасных) системных вызовов. Например, можно запретить приложению использовать системный вызов execve, который часто применяют эксплоиты, или заблокировать системный вызов listen, с помощью которого можно повесить на сетевой порт бэкдор.

Технология используется в Android уже достаточно давно, но применяется в основном к системным компонентам. В Android 8 seccomp-фильтр внедрен в zygote — процесс, который порождает процессы всех установленных в систему приложений.

Разработчики проанализировали, какие системные вызовы нужны для загрузки ОС и работы большинства приложений, а затем отсекли лишние. В итоге в черный список попали 17 из 271 системного вызова на ARM64 и 70 из 364 на ARM. В списке оказался и системный вызов для подключения swap-раздела, так что, возможно, в Android 8 приложения для активации свопа не заведутся.

Защита ядра

За прошлый год более трети уязвимостей Android были найдены в ядре. 45% уязвимостей ядра, начиная с 2014 года, вызваны отсутствием проверки границ в функциях копирования данных из памяти ядра в память процесса и обратно. Патчи с решением данной проблемы были приняты в ядро Linux еще в 2016 году (Linux 4.8), но до Android они не дошли: здесь до сих пор используются ядра версий 3.18, 4.4 и других (в зависимости от чипсета). Google бэкпортировала исправления из Linux 4.8 в 3.18 и другие версии ядер Android. Теперь эти изменения доступны как часть Android 8.

Другая связанная с ядром проблема — прямой доступ к памяти процессов из режима ядра. Хотя само ядро обычно не использует эту возможность, некорректно написанные драйверы могут это делать, что приводит к появлению уязвимостей. Для устранения этой проблемы в ARM v8.1 появился механизм PAN (Privileged Access Never), сходный по своей функциональности с системой SMAP (Supervisor Mode Access Prevention) в x86. Он запрещает обращаться к памяти процессов напрямую и принуждает использовать функции копирования памяти.

Процессоры архитектуры ARM v8.1 пока практически не распространены, поэтому разработчики Linux создали софтверный вариант той же функции. Он был интегрирован в Linux 4.3 для платформы ARM и в Linux 4.10 для ARM64. Google бэкпортировала этот механизм во все ядра Android начиная с 3.18.

Также ядра Android 4.4 и выше теперь включают в себя реализацию механизма KASLR (Kernel Address Space Layout Randomization), который рандомизирует участки расположения кода, хипа, данных ядра в памяти при каждой загрузке, делая атаки на ядро более сложными в реализации.

Все ядра 3.18 и выше теперь также включают в себя функцию post-init read-only memory, помечающую участки памяти, которые были доступны для записи во время инициализации ядра, как read-only уже после инициализации.

Защита нативного кода

С самых первых версий Android поддерживал приложения, написанные не только на Java, но и на языках C, C++ и других, которые можно скомпилировать в нативный код. Такой код размещался в разделяемой библиотеке внутри пакета приложения и мог быть загружен в память с помощью механизма JNI.

И хотя такой код оставался отрезанным от основной системы с помощью песочниц, он мог создать проблемы самому приложению. Допустить ошибку в коде на C++ гораздо проще, чем в коде на Java. Это язык без проверки границ памяти и сборщика мусора. Ошибки переполнения буфера в нем — такая же обыденность, как ошибки обработки путей в веб-приложениях.

Чтобы хоть как-то защитить от взлома приложения, содержащие нативный код, Google запретила загружать в приложение, собранное для Android 8, библиотеки, в которых есть сегменты, помеченные одновременно как исполняемые и записываемые. Это один из простейших методов борьбы с атаками на переполнение буфера, но раньше он применялся только в отношении компонентов самой ОС.

Скрытие информации об устройстве

Android 8 скрывает различную информацию, позволяющую идентифицировать устройство, от приложений и других устройств. Android ID (Settings.Secure.ANDROID_ID), уникальный идентификатор Android, теперь различен для каждого установленного приложения. Серийный номер устройства (android.os.Build.SERIAL) недоступен приложениям, собранным для Android 8 и выше. Вместо него теперь необходимо использовать метод Build.getSerial(), который требует подтверждения полномочия на доступ к функциям чтения информации о смартфоне. Содержимое поля net.hostname теперь пусто, а DHCP-клиент никогда не посылает хостнейм DHCP-серверу.

Другие недоступные сторонним приложениям данные:

• ro.runtime.firstboot — время последней загрузки;
• htc.camera.sensor.front_SN — серийный номер камеры (на устройствах HTC);
• persist.service.bdroid.bdaddr — MAC-адрес Bluetooth;
• Settings.Secure.bluetooth_address — MAC-адрес Bluetooth, теперь доступен только приложениям, у которых есть разрешение LOCAL_MAC_ADDRESS.

Для получения информации о системных аккаунтах теперь недостаточно разрешения GET_ACCOUNTS. По умолчанию приложение может получить доступ только к своим аккаунтам (например, Gmail → аккаунт Google) и должно явно спрашивать пользователя о доступе к другим.

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

Рандомизация MAC-адреса Wi-Fi

Мобильные ОС используют широковещательные запросы Wi-Fi не только чтобы найти точку доступа для подключения, но и чтобы определить местоположение устройства в помещении. У Google и Apple есть база MAC-адресов точек доступа и их географического расположения. Получив ответ от очередной точки доступа, устройство отправляет его MAC на сервер и в ответ получает координаты.

Этот механизм отлично работает, но его же можно повернуть и другим образом. Крупные торговые центры используют его, чтобы отслеживать по MAC-адресам смартфонов перемещения покупателей, более мелкие магазины — чтобы узнать, сколько раз тот или иной покупатель приходил к ним. Но еще есть спецслужбы и те, кто могут продавать такую информацию на третью сторону.

Один из методов борьбы с этим явлением — полное отключение любых сканов Wi-Fi. В Android 6, 7, 8 это можно сделать, отключив опцию Settings → Location → Scanning → Wi-Fi Scanning, в более старых версиях — через расширенные настройки Wi-Fi. Но гораздо более правильный подход — рандомизировать MAC-адрес при каждом скане. В iOS такая функция появилась еще в восьмой версии, однако до Android, в силу огромной фрагментации и существования множества производителей чипсетов Wi-Fi, она добралась только сейчас.

Функция рандомизации должна работать как минимум в Pixel, Pixel XL и Nexus 5X.

WebView в отдельном процессе

WebView — это базирующийся на Chromium компонент Android, позволяющий приложениям отображать в своем окне веб-страницы. Его используют очень многие приложения, включая большую часть сторонних браузеров.

У WebView есть проблема — он работает в том же процессе, что и само приложение. Другими словами: если WebView падает, он забирает с собой приложение, если в WebView обнаруживают уязвимость, с помощью которой можно получить контроль над процессом, — контроль можно получить над всем приложением.

В Android 8 WebView изолирован. Он работает в отдельном процессе в своей собственной, очень ограниченной песочнице, которая не допускает обращения ни к постоянной памяти, ни к интернету. Эту работу должно выполнять само приложение, а WebView остается только отображать страницу.

Кроме того, WebView теперь также может использовать технологию Safe browsing, знакомую всем пользователям Chrome. Safe browsing предупреждает о потенциально небезопасных сайтах и требует явно подтвердить переход на такой сайт.

Пароль на доступ к опциям для разработчиков

Раздел настроек с опциями для разработчиков содержит массу инструментов для отладки и дампа информации об устройстве. Самый опасный из них ADB — средство отладки, позволяющее получить доступ к системному журналу, массе системной информации и даже командной строке.

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

В Android 8 настройки для разработчиков действительно защищены. К ним нельзя получить доступ, не введя пароль блокировки экрана.

Запрет на скрытое получение полномочий

Одним из главных нововведений Android 6.0 стала система подтверждения полномочий. Приложения стали получать права на использование тех или иных функций смартфона не сразу после установки, а только после явного подтверждения со стороны пользователя.

Это очень важное нововведение, которое тем не менее страдает от одной очень большой проблемы. Оно работает только для приложений, собранных под Android 6.0 и выше. Другими словами, если разработчик приложения укажет в правилах сборки targetSdkVersion 22 (то есть Android 5.1), его приложение получит все полномочия автоматически.

Google была вынуждена реализовать систему именно таким образом, чтобы сохранить совместимость со старым софтом, и, естественно, эту особенность сразу начали эксплуатировать создатели разного рода вирусов. Более того, ее используют даже некоторые крупные разработчики (привет, Snapchat), чтобы не отвлекать пользователя окошками о необходимости подтверждать полномочия.

Чтобы хоть как-то снизить риски, Google реализовала нечто под названием runtime-only permissions. Это защита, которая закрывает определенные полномочия для использования, пока приложение не запросит их явно, вне зависимости от того, для какой версии Android собрано приложение.

Пока в списке таких полномочий числится только ANSWER_PHONE_CALLS, то есть возможность отвечать на звонки.

Функция автозаполнения полей и форм

Менеджер паролей с функцией автозаполнения — очень удобное и полезное приложение, особенно в том случае, если подключать смартфон к Google нет никакого желания. Но есть у таких приложений одна серьезная проблема: все они используют в своей работе сервис Accessibility, который не только дает практически полный контроль над смартфоном, но и серьезно влияет на производительность (в конце концов, Accessibility был придуман совсем для других целей).

Чтобы устранить этот недостаток, Google реализовала систему Autofill, которая позволяет приложениям заполнять поля стандартным безопасным способом без использования костылей и распорок.

Режим инкогнито в клавиатуре

Клавиатура Android (как и многие сторонние клавиатуры) использует множество механизмов персонализации для помощи при вводе текста. Это и запоминание сделанного выбора автодополнения, и пользовательский словарь, и логирование введенного текста. Клавиатура Gboard ко всему прочему еще и отсылает весь введенный текст на серверы Google.

Само собой, такое поведение клавиатуры может быть опасным во многих случаях. Поэтому в Android 8 теперь есть режим инкогнито для клавиатуры, который запрещает ей что-либо запоминать. Он реализован как часть библиотеки совместимости и поэтому может быть активирован и в более ранних версиях системы, если приложение это поддерживает.

Пока поддержка режима инкогнито в клавиатуре есть только в Google Chrome и ночных сборках Firefox.

Одной строкой

• Поддержка SSLv3 отключена из-за уязвимости Poodle Attack.
• HttpsURLConnection больше не пытается переключиться на более низкую версию TLS, если сервер некорректно отвечает на запрос о поддерживаемой версии.

Выводы

Система безопасности Android совершенствуется с выходом каждой новой версии ОС. Google реализует огромное количество защитных механизмов, но проблема безопасности Android остается острой. Большинство текущих смартфонов на Android 7 никогда не получат обновление до Android 8, для тех, что работают на более ранних версиях, вероятность обновления стремится к нулю.

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