Не является секретом тот факт, что ядро Android во многом основано на ядре Linux и повторяет его модель безопасности. Как в случае с Linux и другими десктопными ОС, Android обеспечивает свои приложения закрытым виртуальным адресным пространством, что позволяет эффективным образом распределять ресурсы между ними, а также управлять их безопасностью. Android также обеспечивает приложения защитными технологиями DEP & ASLR, что препятствует эксплуатации уязвимостей в них. Механизм sandbox и система прав (permissions) гарантируют, что запущенное приложение получит доступ только к предназначенным для него данным и ресурсам.



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

По словам авторов, новые версии Android будут предлагать технологию DEP в режиме ядра, что затруднит эксплуатацию LPE-уязвимостей и размещение там шелл-кода. Такая техника будет выполнена за счет сегментации, т. е. разделения памяти ядра на специальные разделы с установкой разрешений для них. Разделы, предназначенные для хранения кода, будут помечены как доступные только на чтение и исполнение, а разделы данных будут помечены с запретом на исполнение NX.

This feature segments kernel memory into logical sections and sets restrictive page access permissions on each section. Code is marked as read only + execute. Data sections are marked as no-execute and further segmented into read-only and read-write sections.

Другая функция безопасности похожа на используемую десктопными микропроцессорами Intel защитную меру Supervisor Mode Access Prevention (SMAP), которая предотвращает доступ коду режима ядра к пользовательской части адресного пространства. Android вводит ограничительное меры, которые изолируют ядро от прямого доступа к такой памяти.

This feature improves protection of the kernel by preventing it from directly accessing userspace memory. This can make a number of attacks more difficult because attackers have significantly less control over kernel memory that is executable, particularly with CONFIG_DEBUG_RODATA enabled.

Еще одна защитная мера направлена на предотвращение атак на память стека ядра типа buffer overflow.

Much like its predecessor, stack-protector, stack-protector-strong protects against stack buffer overflows, but additionally provides coverage for more array types, as the original only protected character arrays. Stack-protector-strong was implemented by Han Shan and added to the gcc 4.9 compiler.

Перечисленные защитные меры относятся к работе ядра Android с памятью, другая категория новых защитных мер называется Attack Surface Reduction (ASR), т. е. в нее входят концептуальные защитные меры, которые сразу же отсекают успешное использование целых классов атак.

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

The kernel’s perf system provides infrastructure for performance measurement and can be used for analyzing both the kernel and userspace applications. Perf is a valuable tool for developers, but adds unnecessary attack surface for the vast majority of Android users. In Android Nougat, access to perf will be blocked by default.

ASR также ограничивает приложениям доступ к выполняемым IOCTL-операциям над устройствами через системный вызов ioctl(). Так как для эксплуатации некоторых типов уязвимостей используется именно ioctl, ASR вводит понятие белого списка (whitelist) операций IOCTL, которые будут разрешены приложению для использования.

In Android Nougat, only a small whitelist of socket ioctl commands are available to applications. For select devices, applications’ access to GPU ioctls has been similarly restricted.

ASR вводит новую функцию под названием Seccomp, которая является дополнительной настройкой безопасности для механизма изоляции приложений под названием sandbox. Seccomp позволяет ограничить выполняемое в Android приложение от выполнения некоторых системных вызовов или передачи туда определенных аргументов с использованием специального фильтра. Стоит отметить, что данная функция похожа на указанную нами функцию win32k syscalls filtering, которая появится у пользователей Windows 10 уже на следующей неделе вместе с большим обновлением для этой ОС.

Seccomp provides an additional sandboxing mechanism allowing a process to restrict the syscalls and syscall arguments available using a configurable filter. Restricting the availability of syscalls can dramatically cut down on the exposed attack surface of the kernel. Since seccomp was first introduced on Nexus devices in Lollipop, its availability across the Android ecosystem has steadily improved. With Android Nougat, seccomp support is a requirement for all devices. On Android Nougat we are using seccomp on the mediaextractor and mediacodec processes as part of the media hardening effort.

Указанные функции безопасности должны появиться в новом выпуске Android 7.0 (Nougat).

image
be secure.
Поделиться с друзьями
-->

Комментарии (2)


  1. Alexey2005
    01.08.2016 11:34
    -1

    Что толку с этих усовершенствований механизма безопасности, если через месяц там найдут дыру, закрыть которую можно будет исключительно заменой устройства на новое?
    Отсутствие централизованного обновления — вот самая масштабная дыра в безопасности Android.
    Поэтому лучше бы они усовершенствовали систему обновления Android, чтобы абсолютно любое устройство могло обновиться непосредственно с серверов Google до самой последней версии. Ну или хотя бы делали как Microsoft, выпуская секьюрити-багфиксы даже для старых версий Android, чтобы эти фиксы могли устанавливаться централизованно.
    Почему-то же десктопные операционки на x86 платформе могут обновляться вне зависимости от того, выкатил ли производитель обновление, а почему в Android так нельзя?


    1. snuk182
      01.08.2016 12:04
      +1

      потому что десктоп — это на 99% просто сборник девайсов, на каждый из которых есть драйвер, выпускаемый производителем девайса, и поддержка драйвера в актуальном состоянии это головная боль его производителя, не более. девайс устарел и забыт — вынул его, вставил новый.
      в случае телефонов — это SOC, где под каждое устройство свое ядро, далеко не всегда свежее, далеко не всегда хорошо написанное. драйверы туда вколочены намертво, и обновлять их — задача совершенно не тривиальная. а если у устройства еще и специальные фичи, код на которые закрыт вендором, никто кроме вендора (или очень мотивированного и опытного человека) с этим устройством ничего не сделает.