В TrustZone обнаружены уязвимости

В TrustZone обнаружены уязвимости

В TrustZone обнаружены уязвимости

Исследователи безопасности из группы Zero, опубликовали результаты поиска уязвимостей в технологии ARM TrustZone, позволяющей создавать аппаратно изолированные защищённые окружения, в которых выполняется отдельная специализированная операционная система.

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

В исследовании рассмотрены реализации двух TEE-окружений (Trusted Execution Environment) - Qualcomm QSEE и Trustonic Kinibi, применяемых в Android-смартфонах и базирующихся на расширениях ARM TrustZone. Обе системы предоставляют урезанные проприетарные операционные системы, работающие на отдельном виртуальном процессоре и позволяющие выполнять специализированные защищённые обработчики (TA, Trusted Applications"). Защищённые обработчики не могут напрямую взаимодействовать с основной операционной системой Android, их вызов и передача данных осуществляется косвенно, через интерфейс диспетчеризации, работу которого обеспечивает устанавливаемые в основной системе библиотеки, процессы-демоны и модули ядра, пишет opennet.ru.

 

 

Исследование показало недостаточный уровень безопасности рассмотренных решений, в которых было выявлено несколько уязвимостей, а также одна кардинальная архитектурная недоработка (возможность отката на старую уязвимую версию обработчиков в защищённом окружении), которую невозможно устранить без изменений на аппаратном уровне или снижения стабильности работы устройства. Выполняемые внутри защищённых окружений операционные системы в полной мере не реализуют современные методы блокирования атак (например, защиту от переполнения стека), что позволяет использовать выявленные уязвимости для совершения реальных атак. Проблемы проявляются во всех устройствах на чипах Qualcomm и устройствах на чипах Trustonic Kinibi версии до 400 (т.е. все устройства на базе Samsung Exynos, кроме Galaxy S8 и S8 Plus).

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

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

CodeScoring представила OSA Proxy для защиты цепочки поставок ПО

Платформа CodeScoring представила новый сервис OSA Proxy — инструмент для контроля безопасности компонентов с открытым исходным кодом ещё до того, как они попадут в корпоративную инфраструктуру. Решение стало частью модуля CodeScoring.OSA и ориентировано на защиту цепочки поставок ПО на самом раннем этапе разработки.

В отличие от классического подхода, когда композиционный анализ проводится уже после загрузки зависимостей, OSA Proxy работает в момент установки пакетов.

Сервис перехватывает запросы пакетных менеджеров к внешним индексам и проверяет сторонние компоненты на соответствие заданным политикам безопасности. Если версия пакета признана небезопасной, её можно заблокировать ещё до появления в среде разработки.

OSA Proxy поддерживает популярные экосистемы и репозитории, включая Maven Central, NPM, PyPI, NuGet, Go Modules и пакеты Debian, а также альтернативные хранилища, совместимые с официальными спецификациями. При этом сервис не привязан к конкретным хранилищам артефактов и может работать как с ними, так и вовсе без них — в зависимости от того, как устроена инфраструктура в компании.

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

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

OSA Proxy доступен всем пользователям модуля CodeScoring.OSA и ориентирован на компании, которые хотят усилить контроль за использованием open source без серьёзных изменений в существующих процессах разработки и инфраструктуре.

Платформа CodeScoring представила новый сервис OSA Proxy — инструмент для контроля безопасности компонентов с открытым исходным кодом ещё до того, как они попадут в корпоративную инфраструктуру. Решение стало частью модуля CodeScoring.OSA и ориентировано на защиту цепочки поставок ПО на самом раннем этапе разработки.

В отличие от классического подхода, когда композиционный анализ проводится уже после загрузки зависимостей, OSA Proxy работает в момент установки пакетов. Сервис перехватывает запросы пакетных менеджеров к внешним индексам и проверяет сторонние компоненты на соответствие политикам безопасности. Если версия пакета признана небезопасной, её можно заблокировать ещё до появления в среде разработки.

OSA Proxy поддерживает основные экосистемы и репозитории — Maven Central, NPM, PyPI, NuGet, Go Modules и пакеты Debian, а также альтернативные хранилища, совместимые с официальными спецификациями. При этом сервис не привязан к конкретным хранилищам артефактов и может работать как с ними, так и вовсе без них — в зависимости от архитектуры инфраструктуры.

Технически решение выступает в роли прокси между пакетным менеджером и внешним репозиторием. Оно анализирует манифесты зависимостей и отдельные пакеты, может фильтровать небезопасные версии, изменять ответы сторонних репозиториев, пересчитывать контрольные суммы и перенаправлять ссылки, сохраняя корректность форматов и стабильность сборки.

Для команд предусмотрены разные режимы работы — от мониторинга до активной блокировки компонентов. Это позволяет настраивать уровень контроля в зависимости от требований конкретного проекта. В основе сервиса используется асинхронная модель обработки запросов и механизм автоматических повторов, что обеспечивает стабильную работу даже при высокой нагрузке или временных сбоях внешних сервисов.

OSA Proxy доступен всем пользователям модуля CodeScoring.OSA и рассчитан на компании, которые хотят усилить контроль за использованием компонентов с открытым исходным кодом без существенных изменений в существующих процессах разработки и инфраструктуре.

RSS: Новости на портале Anti-Malware.ru