02.02.2021 06:51
aalbova 22 2500 Источник


Всем привет! В ОС Аврора мы уделяем большое внимание обеспечению безопасности. Сегодня немного расскажем о перспективном подходе — синергии технологии ARM TrustZone и open-source проекта Linux Kernel Runtime Guard (LKRG) для повышения защищённости девайсов (в том числе от zero-day уязвимостей). Поговорим о том, что такое вообще ARM TrustZone, продукт Аврора ТЕЕ, пройдёмся по внутреннему миру LKRG и его ограничениям. Затем о том, как с использованием доверенной среды исполнения можно преодолеть эти ограничения, для того чтобы LKRG можно было рассматривать для применения в продакшене ОС.

Cтатья была подготовлена по материалам доклада нашего коллеги Антона Рыбакова на конференции OS-DAY 2020 https://youtu.be/jjYJKZK_bas

Итак, для начала краткое содержание:


• О технологии ARM TrustZone и Аврора ТЕЕ
• О проекте Linux Kernel Runtime Guard
• Ограничения Linux Kernel Runtime Guard
• Устранение недостатков с помощью ARM TrustZone


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

О технологии ARM TrustZone



На сегодняшний день практически все SoC для мобильных устройств базируются на ARM-процессорах реализующих спецификации Cortex-A [1] ARMv7-A/v8-A [2], и, как правило, обладают поддержкой технологии ARM TrustZone [3]. Эта технология позволяет организовать доверенную среду исполнения — Trusted Execution Environment (TEE), изолированную от основной операционной системы. Доверенная среда исполнения используется для запуска приложений, требующих повышенного уровня безопасности, например — биометрической идентификации, платёжных систем и т. д. На рис. 1 представлена схема работы ARM TrustZone.

Рисунок 1: ARM TrustZone — аппаратная изоляция сред исполнения

ARM TrustZone основывается на аппаратном разделении ресурсов между двумя состояниями процессора — основным и доверенным. Помимо этого ARM предоставляет дополнительные IP-блоки контроллеров памяти и периферии — TrustZone Address Space Controller (TZASC) [4], а также TrustZone Protection Controller (TZPC) [5]. Эти блоки позволяют запретить доступ к определённым участкам адресного пространства или периферийным устройствам из обычного режима исполнения (основной ОС). Переключение между основным и доверенными режимами исполнения ядра процессора осуществляется путём вызова специальной инструкции — SMC (Secure Monitor Call), см. рис. 2.

Рисунок 2: Переключение режима исполнения в ARM TrustZone

С точки зрения архитектурного исполнения возможны различные варианты организации доверенной среды (см. рис. 3):

• выделение одного из вычислительных ядер SoC для исполнения TEE;
• попеременное переключение вычислительных ядер в режим доверенного исполнения по запросу;
• вынос части функционала доверенной среды (как правило — криптографических операций) в отдельный процессор и взаимодействие с ним по внешним интерфейсам.


Рисунок 3: Архитектурные варианты реализации ТЕЕ

Одним из преимуществ реализации архитектурного решения ТЕЕ на основе ARM TrustZone является возможность задействования при необходимости всех аппаратных ресурсов SoC для выполнения доверенных сервисов — например, для проведения биометрической идентификации в безопасной среде. Также возможны смешанные реализации TEE вида: SoC с поддержкой ARM TrustZone и дополнительный внешний сопроцессор, который как правило используется для совершения криптографических операций.

С точки зрения высокоуровнего взаимодействия, обмен данными между основной средой исполнения и доверенной, как правило, организуется на основе использования стандартизованного API по спецификации GlobalPlatform [6].

Производители устройств на базе SoC с ядрами Cortex-A ARMv7/v8 предоставляют программную поддержку доверенной среды исполнения для своих устройств. В последние годы наметилась тенденция к расширению возможностей сервисов доверенной среды. В частности, типичным становится совершение платежей, распознавание отпечатков пальцев, в некоторых смартфонах в доверенной среде проводится идентификация пользователя по радужной оболочке глаза и т. д. Примерами известных ОС для функционирования в среде ARM TrustZone являются Google Trusty [7], Trustonic [8], Samsung TEEGRIS [9]. Как правило, написание сторонних приложений под эти ОС невозможно, так как вендоры мобильных устройств не предоставляют такую возможность.

Мы в компании «Открытая мобильная платформа» занимаемся разработкой ОС «Аврора» для мобильных устройств [10]. Активно развиваемся, в настоящий момент офисы разработки открыты в Иннополисе, Москве и Санкт-Петербурге. Ведётся разработка и развитие собственного продукта для реализации функционала в среде ARM TrustZone под названием «Аврора TEE». «Аврора ТЕЕ» предоставляет приложениям из основной ОС доверенные криптографические сервисы, механизмы управления ключами и безопасного хранения данных, а также аудит основной ОС и состояния устройства в целом как один из механизмов безопасности мобильного устройства.

Чтобы дальше было проще, кратко рассмотрим режимы исполнения процессоров архитектуры ARM Cortex-A для дальнейшего использования в сокращениях. Семейство Cortex-A ARMv8-A имеет следующий набор режимов исполнения (Exception Levels): EL0 для исполнения пользовательских программ, EL1 — для исполнения ядра основной ОС, EL2 — уровень гипервизора, EL3 — монитор безопасности для переключения между нормальным и безопасным (в ARM TrustZone) режимами исполнения, S-EL0 — для исполнения доверенных сервисов, S-EL1 — для исполнения доверенной ОС, S-EL2 — для доверенного гипервизора. Для архитектуры Cortex-A ARMv7-A набор режимов исполнения идентичен, за исключением S-EL2 (введён в спецификации ARMv8.4-A).

Посмотрим теперь, какие задачи нам нужно решить. Считаем, что защита ОС мобильных устройств на уровне исключений EL1, а также пользовательских приложений исполняющихся на уровне EL0 ставит перед собой, кроме прочего, следующие задачи:
• защита исполняемого кода ядра ОС на уровне EL1 от модификации в ходе применения эксплоитов, а также для предотвращения развёртывания руткитов в завершающей фазе атаки
• защита внутренних структур и механизмов ядра на уровне EL1
• контроль над разрешениями (credentials) исполняемых пользовательских процессов для предотвращения эксплуатации уязвимостей в приложениях уровня EL0 и повышения привилегий до уровня root.

О проекте Linux Kernel Runtime Guard



Многие современные механизмы защиты основываются на усилении существующих мер безопасности. Например, задействуются различные программные и программно-аппаратные механизмы — Safe Stack, Pointer Authenthication и т. д. При этом, если злоумышленник находит способ преодолеть эти механизмы, то он получает возможность дальнейшей компрометации данных без риска быть обнаруженным.

Среди проектов для реализации мер безопасности существует проект с открытым исходным кодом, распространяемый по лицензии GPLv2 под названием Linux Kernel Runtime Guard (LKRG) [11]. Его особенностью является пост-детектирование факта совершения атаки, что позволяет обнаруживать применение эксплоитов, преодолевших традиционные механизмы защиты. Это позволяет потенциально защитить ОС от атак, механизм действия которых на настоящий момент неизвестен или от атак, эксплуатирующих уязвимости, не обнаруженные в текущее время. При этом важно отметить, что реагирование на вредоносное воздействие производится до того, как запрошенная операция будет непосредственно выполнена. Функционально LKRG состоит из 2х основных модулей — Exploit Detection (ED), для обнаружения воздействия на пользовательские процессы исполняющиеся на уровне EL0, и Integrity Timer (IT), для обнаружения воздействия на код ядра ОС уровня EL1.

Модуль Exploit Detection контролирует пользовательские процессы. Проверка состояния их структур на входе/выходе отслеживаемых функций ядра ОС Linux позволяет обнаруживать злонамеренное повышение привилегий, в частности — подмену указателей на структуры с токенами аутентификации / разрешениями, а также перезапись этих структур, в том числе с использованием внутренних вызовов ядра; злонамеренное изменение конфигурации и правил seccomp; злонамеренное изменение пространства имён и выход за пределы контейнеров. Данный модуль LKRG также контролирует поток управления путём разворота стека вызовов при входе в отслеживаемые функции ядра, при этом происходит обнаружение использования техники Return Oriented Programming (ROP), дополнительно детектируются атаки направленные на подмену стека вызовов и передачу управления в области за пределами ядра ОС.

Второй основной модуль LKRG, Integrity Timer, осуществляет проверку целостности непосредственно ядра ОС Linux. Отслеживается текущее состояние вычислительных ядер процессора и системных регистров, вычисляется контрольная сумма кодовой базы ядра и модулей и производится периодическая проверка на совпадение вычисленной контрольной суммы и актуального состояния. Также отслеживаются изменения в таблицах обработчиков прерываний, системных вызовов и производится контроль глобальных переменных ядра, непосредственно влияющих на обеспечение безопасности, в частности — selinux_enabled / selinux_enforcing / selinux_state и т. д.

Рисунок 4: Функциональная схема проекта LKRG

Схема работы LKRG представлена на рис.4. Она показывает, что в качестве источников данных используются сведения, полученные на входе/выходе из контролируемых при помощи механизма k(ret)probes функций ядра. Собранные данные при помощи модулей контролирующей логики сравниваются с ожидаемым состоянием системы, которое хранится в БД каждого из модулей. Причём, для Exploit Detection контроль происходит при наступлении каждого события, а для Integrity Timer проверка осуществляется с некоторым интервалом по срабатыванию системного таймера.

Ограничения Linux Kernel Runtime Guard



При наличии несомненных плюсов, у данного проекта есть также определённые недостатки:

  1. Для работы LKRG требуются отладочные механизмы k(ret)probes [12], включение которых в состав ядра ОС увеличивает поверхность атаки, так как кодовая база ядра для нормальной работы данного механизма должна иметь атрибуты страниц памяти с режимом доступа «чтение/запись/исполнение».
  2. Злоумышленник, получив доступ к исполнению кода на уровне ядра, может провести атаку непосредственно на сам механизм LKRG — модифицировать его базы данных, выявить и нейтрализовать контексты исполнения, изменить состояние системных таймеров для отключения периодической проверки модулем Integrity Timer.


Снятие ограничений с помощью ARM TrustZone



Решить проблему №1, связанную с включением в состав ядра ОС механизма k(ret)probes можно путём установки k(ret)probes из доверенной среды исполнения. Это даёт возможность держать кодовую базу ядра в нормальном режиме исполнения с постоянными атрибутами страниц «чтение/исполнение», а также позволяет дополнительно проконтролировать тот факт, что функция, которая является источником данных для LKRG, действительно вызвана срабатыванием исключения для установленных k(ret)probes.

Реализуется данный механизм следующим образом: кодовая база ядра ОС общего назначения всегда имеет атрибуты страниц памяти «чтение/исполнение», при этом из доверенного режима данный регион памяти доступен в режиме «чтение/запись». Далее, при загрузке модуля LKRG в ядро и регистрации k(ret)probes для контроля функций ядра, необходимые адреса передаются в доверенную среду, и из доверенной среды происходит расстановка в области .text ядра ОС общего назначения опкодов, вызывающих исключение вида «ILLEGAL INSTRUCTION» по указанным адресам. При срабатывании исключения на уровне EL1 происходит запрос переключения в режим S-EL1 для осуществления необходимых действий. При этом, поскольку переключение производится с использованием монитора безопасности уровня EL3, возможно извлечь содержимое регистров ESR_EL1 и FAR_EL1 для того чтобы проконтролировать, что вызов был инициирован из контекста исключения вызванного исполнением «ILLEGAL INSTRUCTION» по установленному ранее адресу. Данный способ представлен на Рис. 5.

Рисунок 5: Схема установки k(ret)probes из доверенной среды исполнения

Устранение проблемы №2, связанной с возможностью проведения атаки на сам механизм LKRG, может быть также реализовано путём выноса части функциональных частей в доверенную среду исполнения, в частности — в ARM TrustZone.

Так, на уровни в S-EL0/1 могут быть перенесены базы данных со сведениями об эталонном состоянии контролируемой ОС, а также контролирующая логика. Вызов системного таймера в ОС Linux для активации механизма Integrity Timer может быть заменён на прерывание из доверенного режима исполнения, инициированное срабатыванием защищённого таймера, недоступного для модификации из обычного режима. На уровне EL1 в основной ОС механизм LKRG трансформируется таким образом в агент по сбору данных для последующей обработки в доверенном режиме исполнения. При этом важно отметить, что реагирование на выявленные нарушения производится также из доверенной среды, что в свою очередь защищает от атаки непосредственно на механизм реагирования на нарушение. Схема выноса функционала LKRG в доверенную среду исполнения представлена на Рис. 6

Рисунок 6: Вынос компонентов LKRG в доверенную среду исполнения

Мы рассмотрели набор компонентов для защиты мобильных устройств от злонамеренного воздействия, который может быть принят для организации мер безопасности: доверенная загрузка исполняемых компонентов ( основной ОС и доверенной среды) как гарантия целостности кодовой базы, контроль ОС общего назначения с использованием модуля LKRG, и усиление защиты путём выноса функциональных частей LKRG в доверенную среду исполнения, в частности, в ARM TrustZone.

Подробнее об операционной системе Аврора, устройствах на ее платформе, а также о ресурсах для разработчиков приложений можно узнать на сайте auroraos.ru

P.S. Защита ОС с использованием аппаратных средств не самая простая тема для изложения, но мы старались :)

Список использованных источников и литературы:

[1] ARM Ltd. Sales and market share. URL: en.wikipedia.org/wiki/Arm_Ltd.#Sales_and_market_share

[2] Arm Architecture Reference Manual Armv8, for Armv8-A architecture profile.
URL: developer.arm.com/documentation/ddi0487/latest

[3] TrustZone technology for Armv8-A. URL:
developer.arm.com/ip-products/security-ip/trustzone/trustzone-for-cortex-a

[4] About the TZASC. URL: developer.arm.com/documentation/ddi0431/c/introduction/about-the-tzasc

[5] PrimeCell Infrastructure AMBA 3 TrustZone Protection Controller (BP147). URL: developer.arm.com/documentation/dto0015/a

[6] Global Platform. Technology Document Library. URL: globalplatform.org/specs-library/?filter-committee=tee

[7] Trusty TEE. URL: source.android.com/security/trusty

[8] Trustonic TEE. URL: www.trustonic.com/technical-articles/what-is-a-trusted-execution-environment-tee

[9] SAMSUNG TEEGRIS. URL: developer.samsung.com/teegris/overview.html

[10] Мобильная ОС Аврора. URL: auroraos.ru

[11] LKRG — Linux Kernel Runtime Guard. URL: www.openwall.com/lkrg

[12] Kernel Probes (Kprobes). URL: www.kernel.org/doc/html/latest/trace/kprobes.html