ИБ-исследователь Гектор Мартин рассказал о найденной им уязвимости открытого канала в архитектуре чипа Apple М1, которую нельзя исправить. Он назвал ее M1racles (CVE-2021-30747). С помощью этого аппаратного бага можно передавать данные с настолько быстрой скрытой передачей данных между двумя приложениями различных пользователей в системе, что её хватает на видеопоток. Это происходит на уровне одного из каналов в вычислительном ядре чипа M1. С виртуальными машинами «уязвимость открытого канала» не работает.
M1RACLES — это сокращение от M1ssing Register Access Controls Leak EL0 State (утечка контроля доступа к регистру состояния в режиме EL0).
Системный регистр архитектуры ARM под кодом s3_5_c15_c10_1 доступен из режима EL0 и содержит два бита, которые могут быть прочитаны или записаны (биты 0 и 1). Этот регистр доступен для каждого кластера, к которому могут одновременно обращаться все ядра кластера, что делает его двухбитным скрытым каналом, который любой произвольный процесс может использовать для обмена данными с другим взаимодействующим процессом. Мартин опубликовал на GitHub демо-приложение для доступа к этому регистру.
Пара взаимодействующих процессов может построить устойчивый канал из этого двухбитового состояния, используя протокол синхронизации и данных (например, одна сторона записывает 1x для отправки данных, другая сторона записывает 00 для запроса следующего бита). Это позволяет двум процессам (приложениям) обмениваться произвольным объемом данных, ограничиваясь только накладными расходами ЦП. У Мартина получилось без особой оптимизации достичь скорости передачи более 1 МБ/с.
Мартин уточнил, что первоначальное назначение этого регистра неизвестно. Он предполагает, что он не был специально сделан доступным из режима EL0, что делает инцидент аппаратной ошибкой, которую Apple не сможет исправить программными обновлениями. В компании в курсе уязвимости M1. Там считают, что злоумышленники не смогут ее использовать, так как процесс передачи данных работает исключительно в рамках одного ПК и только при инициировании специальной команды отправки, а передача во внешнюю среду невозможна без разрешения пользователя.
Примечательно, что уязвимость M1racles позволяет создавать скрытый канал для незаметного (при штатной работе системы) обмена данными между двумя процессами, запущенными от имени разных пользователей и с разными уровнями привилегий. Фактически любые два приложения, работающие под управлением операционной системы macOS или Linux, могут обмениваться данными по высокоскоростному каналу без использования памяти, сокетов, файлов или других «нормальных» возможностей ОС.
Мартин считает, что в самом худшем случае эту уязвимость могут использовать, например, рекламные компании для отслеживания действий пользователей между своими приложениями.
Пример использования уязвимости M1RACLES с передачей видео между приложениями.
Мартин с конца прошлого года занимается краудфандинговым проектом Linux для Maс на M1 — Asahi Linux. Именно в рамках изучения архитектуры М1 по этому проекту он смог обнаружить
уязвимость M1RACLES.
SergeyMax
Pyhesty
TCP будет заметно и можно предотвратить, а это похоже на программно-аппаратный бэкдор, когда на уровне ядра есть универсальный ответчик, а внедренная позже программа через ответчик может получить доступ к любым данным и отправить их зашифрованным способом опять же инструментами на уровне ядра. Но зависит от аппаратной поддержки бэкдора, но когда кому-то нужно ее внедрить - она есть (например, во время индивидуального обновления, которое замаскировано под общее обновление безопасности)
Coriolis
Какой еще ответчик на уровне ядра? Тут один специально подготовленный процесс может обмениваться инфой с другим специально подготовленным процессом. Ответчиком выступает специально подготовленный процесс а не какое-то там "ядро".
Pyhesty
специально для нужного объекта делают сборку обновления, которое обновит ядро ОС (или изначально объект получает устройство с нужной модификацией ОС), и теперь на Ring0 уровне будет универсальный ответчик, далее в нужный момент вам доставляются приложения требующие минимальные привилегии, которые собирают данные которые им нужны, через встроенную аппаратно-программный бэкдор, который уже работает с максимальным уровнем привилегий и незаметно для антивирусов и вас. Приложение с минимальным уровнем привилегий внедрить намного проще. Это не массовый бэкдор, пока…
gxcreator
Что мешает туда вшить сразу все, что нужно, без вот этого транспорта?
Pyhesty
мешают антивирусы и всякие службы, которые должны контролировать, что устройство безопасно. Предположим вашей стране дарят в помощь полиции 1000 планшетов для прямой связи с базой данных, вы их проверяете и не находите ничего опасного, запрещаете обновления ОС, но там уже сидит аппаратно-программный бекдор, достаточно одному из 1000 планшетов внедрить на любом уровне нужно приложение и у вас взамен 1000планшетов есть доступ к базам данных полиции этой страны. Вариантов применения таких бэкдоров можно придумать довольно много, но мое мнение это вполне себе бэкдор.
ps:Если у вас паранойя, это не значит, что за вами не следят…
Frankenstine
А что будет мешать этим самым антивирусам обнаруживать эксплуатацию M1RACLES и убивать стрёмный процесс?
Pyhesty
нет механизма перехватить антивирусу работу кода на уровне ядра, в любом случае реализация такого механизма радикально замедлит работу. К тому же сам по себе обмен через этот канал не является вирусом, а только бэкдором между куском кода с максимальными привилегиями с кодом выполняющимся с минимальными привилегиями или даже в песочнице.
dmytro_p
Простите, если можно доставить «специально для нужного объекта» обновление ОС, то зачем заморачиваться каким-то еще приложением и тайным каналом связи с аппаратной поддержкой? Не проще ли включить все необходимые инструменты анализа прямо в обновление?
saboteur_kiev
Запускаешь вирус, который содержит код отправителя, арендуешь машину в том же облаке со считывателем, и надеешься, что ваши процессы попадут на одну ноду.
И все фаерволы и настройки безопасности на уровне пользователя и даже виртуалки — мимо.
Да, уязвимость не та, чтобы ею пользовался каждый скрипткидди, но.
vesper-bot
Дело больше в неотслеживаемости, чем в факте передачи данных. О сокетах, портах и именованных каналах (вроде это только винды, но тоже только локальные) надо просить ядро, а там есть возможности аудита. Кроме того, если приложения сидят каждое в своей песочнице, но через этот регистр смогут друг другу передать данные — хе-хе, sandbox escape в чистом виде.
SergeyMax
abutorin
Это действие ядро отслеживает и может заблокировать.
Можно, один из известных протоколов X-10.
Вся "суть" уязвимости в том, что узнать о передачи информации средствами ядра невозможно. Т.е. много средств предназначенных для отслеживания подозрительной активности не узнают об этом.
Как уже писали, теперь нельзя доверять приложению запущенному в песочнице.
SergeyMax
abutorin
"Дыр" в защите может быть много. От того что "дыра" маленькая не делает её более безопасной. Когда происходит атака используют как правило несколько уязвимостей, каждая из которых в отдельности может не представлять опасности. Конкретно этот случай плох тем, что эту проблему нельзя решить программно. Закрыть уязвимость обновлением ПО нельзя. Значит она так и будет присутствовать на большом количестве устройств.
SergeyMax
Это примерно такая же уязвимость, как возможность открывать порты или создавать общие для процессов отображаемые в память файлы. То есть уязвимостью это становится не в тот момент, когда появилась возможность открыть порт, а в тот момент, когда обработчик порта не проверил поступающие по этому каналу данные (а ядро вам предоставляет для этой уязвимости удобный интерфейс, ха-ха!).
abutorin
Запретить использовать порты приложению можно на уровне ОС. Создавать файлы только в "песочнице" можно на уровне ОС. Запретить использовать регистр вы не можете.
Это все равно что иметь ведро, в котором часть дыр вы закрыть никак не можете, даже не будете знать что через часть дыр вода утекает. Решение только одно: не использовать его совсем.
SergeyMax
Ну в каком-то смысле вы и правы. Но так же вы не можете запретить использовать процессор, память, и диск (пусть даже и в песочнице). И любой общий ресурс — это очевидный side channel для общающихся между собой процессов.
fwiffo
Насколько я помню, приложения в песочнице по умолчанию не имеют доступа к информации о других запущенных процессах. То есть даже если они получат доступ к информации об используемых системных ресурсах (что тоже отслеживается системой), в этой информации будет очень много «шумов» как от самой ОС, так и от других запущенных приложений. То есть в этом случае система знает о запуске вашего утюга и может н анескольких этапах его контролировать.
SergeyMax
habr.com/ru/post/560508
ibrin
Если запускать недоверенные приложения в песочнице по одному за раз, то всё получится безопасно.
alsoijw
SergeyMax
Передать пароль вполне достаточно.
wataru
Но, опять же, все программы этот регистр видят. Так что узнать о передаче данных элементарно. То же ядро может проверять состояние этого регистра переодически и, допустим, убивать приложения, пишущиее туда.
gurux13
Ятп, невозможно отследить, кто (когда?) туда пишет. Эта запись не вызывает прерываний ни в каком режиме процессора.
wataru
Можно при обнаружении не 0 в этом регистре посканировать запущенные приложения на предмет машинных кодов записи/чтения из этих регистров.
gurux13
А это вообще алгоритмически неразрешимая задача :) Если, конечно, не требовать подписи всего выполнимого кода, включая динамически созданный.
Viknet
На iOS собственно так и сделано (на A14, кстати, уязвимость подтверждена). Весь выполняемый код подписан, а динамически генерировать запрещено (и правилами AppStore и архитектурой памяти).
gurux13
Да, я помню, как это мешало писать на Xamarin'е под iOS :) Но я не думаю, что эту политику реально применить к десктопу/ноуту.
Кстати, интересная тема - по подписанному коду определить, пишет он в регистры или нет. Или, скажем, есть ли опкоды записи, которые вероятно использовались (проблема "пишет/не пишет" снова неразрешима).
Viknet
Да, на macOS таких ограничений нет, поэтому и защиты нет.
Вполне разрешима. Это не general purpose регистр, работа с ним ограничена небольшим количеством операций, поиск таких инструкций в секциях кода элементарен, и, скорее всего, уже автоматизирован на ревью в AppStore.
wataru
Зачем? во время смены контекста посмотреть по адресу регистра выполняемой команды и проверить, что там нет ничего криминального.