Комментарии 123
который любой произвольный процесс может использовать для обмена данными с другим взаимодействующим процессомЖёсткая уязвимость. Ещё можно TCP-порт открыть и использовать для обмена данными с другим процессом, вот где дупло так дупло.
TCP будет заметно и можно предотвратить, а это похоже на программно-аппаратный бэкдор, когда на уровне ядра есть универсальный ответчик, а внедренная позже программа через ответчик может получить доступ к любым данным и отправить их зашифрованным способом опять же инструментами на уровне ядра. Но зависит от аппаратной поддержки бэкдора, но когда кому-то нужно ее внедрить - она есть (например, во время индивидуального обновления, которое замаскировано под общее обновление безопасности)
Какой еще ответчик на уровне ядра? Тут один специально подготовленный процесс может обмениваться инфой с другим специально подготовленным процессом. Ответчиком выступает специально подготовленный процесс а не какое-то там "ядро".
сборку обновления
Что мешает туда вшить сразу все, что нужно, без вот этого транспорта?
мешают антивирусы и всякие службы, которые должны контролировать, что устройство безопасно. Предположим вашей стране дарят в помощь полиции 1000 планшетов для прямой связи с базой данных, вы их проверяете и не находите ничего опасного, запрещаете обновления ОС, но там уже сидит аппаратно-программный бекдор, достаточно одному из 1000 планшетов внедрить на любом уровне нужно приложение и у вас взамен 1000планшетов есть доступ к базам данных полиции этой страны. Вариантов применения таких бэкдоров можно придумать довольно много, но мое мнение это вполне себе бэкдор.
ps:Если у вас паранойя, это не значит, что за вами не следят…
Вы невнимательно читали тему. Уязвимость работает на уровне EL0. На EL0 работают пользовательские программы (например ваш браузер). У кода исполняющегося в EL0 нет никаких привилегий: он (обычно) не может работать с периферией, перенастраивать MMU, запрещать (и разрешать тоже) прерывания, обрабатывать исключительные ситуации. Соответственно антивирусу обращение к этому багу перехватить как два пальца об асфальт.
по части анализа кода программы — он может быть модифицируемый в процессе выполнения и тогда только запуск в песочнице спасет (и то не каждой)…
ps: по приведенной ссылке сравнение не корректное
"
Последняя может вызвать у читателя здравое недоумение: на видео, тактовый период кодирующей последовательности был равен 16 мс, и её длина 1023 бит, т.е., передача одного бита занимала примерно 16 секунд, давая скорость около 0.06 бит в секунду. Передача семибайтового файла с CRC и разделителями заняла почти полчаса.
" M1RACLES — скорость передачи более 8 Mb/s
Если у вас время выполнения скрипта секунды, пока он не будет закрыт, то у вас нет получаса на передачу 7 байт…
pss: и в той же статье по вашей ссылке:
"
Hector Martin скорректировал мои заблуждения, указав на то, что уязвимость как абсолютная метрика бессмысленна, всегда необходимо учитывать контекст. В этом смысле, наличие высокоскоростного канала скрытого обмена несколько расширяет множество реализуемых атак, следовательно, M1RACLES является вполне реальной уязвимостью, пусть и по-прежнему крайне малой значимости."
обнаружить (непосредственно в коде или во время выполнения программы) попытку обращения к регистру s3_5_c15_c10_1?Интересно, какой будет процент ложноположительных срабатываний, когда обращение к регистру есть, но это не канал передачи?
И все фаерволы и настройки безопасности на уровне пользователя и даже виртуалки — мимо.
Да, уязвимость не та, чтобы ею пользовался каждый скрипткидди, но.
Дело больше в неотслеживаемости, чем в факте передачи данных. О сокетах, портах и именованных каналах (вроде это только винды, но тоже только локальные) надо просить ядро, а там есть возможности аудита. Кроме того, если приложения сидят каждое в своей песочнице, но через этот регистр смогут друг другу передать данные — хе-хе, sandbox escape в чистом виде.
TCP будет заметно и можно предотвратить, а это похоже на программно-аппаратный бэкдорМожно открыть memory-mapped файл и обмениваться данными через него. В конце концов, обмениваться данными можно даже через утюг: включаете утюг — напряжение в сети падает, это будет логический ноль. Выключаете, напряжение растёт — это будет единица. Даже процессор M1 не нужен.
Можно открыть memory-mapped файл
Это действие ядро отслеживает и может заблокировать.
обмениваться данными можно даже через утюг
Можно, один из известных протоколов X-10.
Вся "суть" уязвимости в том, что узнать о передачи информации средствами ядра невозможно. Т.е. много средств предназначенных для отслеживания подозрительной активности не узнают об этом.
Как уже писали, теперь нельзя доверять приложению запущенному в песочнице.
теперь нельзя доверять приложению запущенному в песочницеЕсли два приложения целенаправленно хотят обменяться данными между собой, вы с этим ничего не сделаете. Одно приложение может нагружать проц, а второе считывать загрузку (аллюзия с утюгом видимо не зашла), и никакое ядро вам тут не поможет. Удивительно, что это является для кого-то открытием.
"Дыр" в защите может быть много. От того что "дыра" маленькая не делает её более безопасной. Когда происходит атака используют как правило несколько уязвимостей, каждая из которых в отдельности может не представлять опасности. Конкретно этот случай плох тем, что эту проблему нельзя решить программно. Закрыть уязвимость обновлением ПО нельзя. Значит она так и будет присутствовать на большом количестве устройств.
Запретить использовать порты приложению можно на уровне ОС. Создавать файлы только в "песочнице" можно на уровне ОС. Запретить использовать регистр вы не можете.
Это все равно что иметь ведро, в котором часть дыр вы закрыть никак не можете, даже не будете знать что через часть дыр вода утекает. Решение только одно: не использовать его совсем.
Если запускать недоверенные приложения в песочнице по одному за раз, то всё получится безопасно.
Одно приложение может нагружать проц, а второе считывать загрузку (аллюзия с утюгом видимо не зашла), и никакое ядро вам тут не поможет.С какой скоростью?
Но, опять же, все программы этот регистр видят. Так что узнать о передаче данных элементарно. То же ядро может проверять состояние этого регистра переодически и, допустим, убивать приложения, пишущиее туда.
Ятп, невозможно отследить, кто (когда?) туда пишет. Эта запись не вызывает прерываний ни в каком режиме процессора.
Можно при обнаружении не 0 в этом регистре посканировать запущенные приложения на предмет машинных кодов записи/чтения из этих регистров.
А это вообще алгоритмически неразрешимая задача :) Если, конечно, не требовать подписи всего выполнимого кода, включая динамически созданный.
Если, конечно, не требовать подписи всего выполнимого кода, включая динамически созданный.
На iOS собственно так и сделано (на A14, кстати, уязвимость подтверждена). Весь выполняемый код подписан, а динамически генерировать запрещено (и правилами AppStore и архитектурой памяти).
Да, я помню, как это мешало писать на Xamarin'е под iOS :) Но я не думаю, что эту политику реально применить к десктопу/ноуту.
Кстати, интересная тема - по подписанному коду определить, пишет он в регистры или нет. Или, скажем, есть ли опкоды записи, которые вероятно использовались (проблема "пишет/не пишет" снова неразрешима).
Но я не думаю, что эту политику реально применить к десктопу/ноуту.
Да, на macOS таких ограничений нет, поэтому и защиты нет.
Или, скажем, есть ли опкоды записи, которые вероятно использовались (проблема "пишет/не пишет" снова неразрешима).
Вполне разрешима. Это не general purpose регистр, работа с ним ограничена небольшим количеством операций, поиск таких инструкций в секциях кода элементарен, и, скорее всего, уже автоматизирован на ревью в AppStore.
Зачем? во время смены контекста посмотреть по адресу регистра выполняемой команды и проверить, что там нет ничего криминального.
Еще одна причина не становиться сразу бетатестером за свои деньги для новых аппаратных платформ.
эту уязвимость могут использовать, например, рекламные компании
а вот за это можно банально банить сами компании и персонально тех, кто это делает. жестко.
Хм… и если м2 уже на конвейере, то исправить уязвимость они не смогут. Печально, но благо она не опасная.
Если этот регистр не нужен для каких-либо операций, то система может по таймеру записывать в него случайный мусор. Это превратит "уязвимость" просто в непонятное значение, которым толком и воспользоваться нельзя.
Начнут пользоваться как каналом с искажениями, передавая ECC-биты.
Там два бита всего в работе. И нет заданной скорости канала, плюс неизвестен интервал записи искажений. Автор статьи использовал один из битов как индикатор RTS/CTS, но он тоже станет не достоверным, значит остаётся только передача с фиксированной скоростью, где задержка должна быть существенно меньше интервала таймера шума.
Ну если через канал шириной в два бита один бит передали 1МБ/с, значит, чтобы его надежно зашуметь, нужно записывать чушь в регистр на частоте не менее 4 8 МГц. По таймеру в ядре такое не сделаешь, придется целый поток выделять, чтобы тот тупо в цикле туда гнал хотя бы нули. А дальше будут вопли "что это за безопасность, у меня система 25% процессора в простое ест!"
Поток, пишущий 1мб/с в память (а точнее, в регистр процессора) так много CPU не должен занять. Плюс, чтобы создать гарантированные потери, достаточно преодолеть предел Шеннона, т.е. SRN должно быть ниже 1.44. Выходит, для 100% защиты можно писать всего 695кб/с шума в этот регистр, что уже дает частоту вызовов "всего" ~5 МГц.
К сожалению, мы не можем знать, насколько это много или мало для данного процессора без дополнительных тестов. Плюс, вполне может быть, что там ограничение скорости связано только с алгоритмом в тестах автора и реально скорость может достигать гигабит в секунду, что делает зашумление не целесообразным.
1 мб/c было в proof of concept с синхронизацией после каждого бита. Если убрать синхронизацию то писать можно сразу по 2 бита, а целостность проверять чексуммой, и значительно быстрее
Там считают, что злоумышленники не смогут ее использовать, так как процесс передачи данных работает исключительно в рамках одного ПК
То же, строго говоря, справедливо и для Spectre, и для Meltdown, и для Rowhammer, и для очень похожей на M1RACLES уязвимости TLBleed. Так что оправдание так себе. Я к тому, что известно, что in the wild пока ничего из этого широко не использовалось (НЯП, были только PoC), но кивать на то, что «это только на локальной машине» — ну такое.
разве?
вроде бы в тех случаях шла речь о чтении или даже записи чужих страниц памяти без помощи стороннего приложения, то есть (условно) «нехорошее приложение сможет украсть пароли из памяти или вообще поменять их».
в данном случае речь про «два нехороших приложения могут скрытно обмениваться данными между собой».
So what's the point of this website?
Poking fun at how ridiculous infosec clickbait vulnerability reporting has become lately. Just because it has a flashy website or it makes the news doesn't mean you need to care.
If you've read all the way to here, congratulations! You're one of the rare people who doesn't just retweet based on the page title :-)
But how are journalists supposed to know which bugs are bad and which bugs aren't?
Talk to people. In particular, talk to people other than the people who discovered the bug. The latter may or may not be honest about the real impact.
If you hear the words “covert channel”… it's probably overhyped. Most of these come from paper mills who are endlessly recycling the same concept with approximately zero practical security impact. The titles are usually clickbait, and sometimes downright deceptive.
Расходимся…
Эхх, очередного журналиста изнасиловали....
Тем не менее уязвимостью данная штука быть не перестает.
Согласно определению с Википедии, эта особенность не является уязвимостью, поскольку не предоставляет атакующему возможностей для реализации новых векторов атаки. Возможность скрытого обмена данными между процессами, исполняемыми на одной машине, будет существовать всегда, покуда есть разделяемые ресурсы. SergeyMax приводит выше совершенно корректный пример с загрузкой процессора или любого другого ресурса, подобающая модуляция которого позволит вам вытащить данные хоть из виртуальной машины. Хотите, сделаем PoC и раздуем из этого ещё одну бесполезную сенсацию?
Я хочу, давайте попробуем, а то так на слово я не верю что бы это работало, ну или так скажем или рабочий пок (готов помочь) или вы соглашаетесь величать меня, императором галактики. Ну и я подразумеваю, что вы согласны на пок, так что сразу к бою, какие параметры будем считать зачетными, минимальная скорость/вероятность передачи данных, максимальные ресурсы которые разрешенно использовать, какие условия испытаний/противодействия системы, сколько максимум усилий на реализацию?
Ох, это был риторический вопрос, потому что принцип давно известен. Вот, например, критический обзор методов атак через кэш: https://arxiv.org/pdf/1606.01356.pdf. Но если вы настаиваете, то давайте сделаем, и напишем об этом статью на хабре с дисклеймером как в верхнем комментарии этой ветки.
какие параметры будем считать зачетными, минимальная скорость/вероятность передачи данных, максимальные ресурсы которые разрешенно использовать, какие условия испытаний/противодействия системы, сколько максимум усилий на реализацию?
Я предлагаю следующую постановку задачи: есть VM на VirtualBox; хост и гость — AMD64 машины, исполняющие современные дистрибутивы GNU/Linux без специальной преднастройки (скажем, Manjaro или что-либо Ubuntu-based в дефолтной конфигурации после установки). Хост исполняет VM и процесс-приёмник; гость, соответственно, исполняет наш процесс-передатчик. Задачу будем считать выполненной, если мы сумеем достичь скорости передачи не менее 1 бит в минуту при BER < 50% (думаю, добиться результата лучше усилий не составит, но это мы всегда успеем). Ограничения на усилия обусловлены нашей готовностью возиться с этим.
Если стартовые условия вас устраивают, я готов поделиться соображениями по практической стороне вопроса.
В целом условия нормальные, есть пара вопросов 1 бит в минуту это конечно точно не успех, т.к. реальной угрозы не представляет. 1 бит в секунду это более менее минимальная скорость для реальных проблем. Вообще нужен двунаправленный канал, он не обязан быть симметричным по скорости, так что бит в секунду суммарно в обе стороны думаю нормальные требования. Ну и дальше по ресурсам, если для достижения таких параметров нужно загрузить цпу на 100% или памяти сожрать десяток гигов, то ни о какой скрытности речи не идёт. Нужно ещё наложить ограничения на гостя по количеству ядер/памяти и загрузки цпу, у хоста тоже должны быть похожие ограничения, но разумно предположить что менее строгие.
Дальше статья, я об этом не думал и вобщем отношусь к этому индефертно, но если уж что то писать то тогда если не получиться это реализовать то это тоже результат который нужно описать, а не только в успешный случай.
Статья про кэш почти десятилетней давности, так что то что было возможно тогда может вообще не сработать сейчас. Вобщем я ставлю на то что у нас это не получится за какое-то разумное время, но у меня нет каких навыков в хакинге, так что я открыт к новому опыту и мне будет интересно ошибиться.
В целом условия нормальные, есть пара вопросов 1 бит в минуту это конечно точно не успех, т.к. реальной угрозы не представляет.
O RLY? Хватит чтобы вытащить пароли и куки. Можно и это продемонстрировать.
Ну и дальше по ресурсам, если для достижения таких параметров нужно загрузить цпу на 100% или памяти сожрать десяток гигов, то ни о какой скрытности речи не идёт.
О скрытности речи в принципе не идёт. Атака по побочным каналам даже через описанный в статье регистр легко мониторится тривиальными инструментами. У меня плазма регулярно нагружает одно ядро на 100%; я не знаю, что она делает в это время, мне без разницы. Вариации потребления системных ресурсов сложными программами вопросы вызывают редко.
Ну, я врядли соглашусь, что 1 бит в минуту представляет опасность, и/или скрытность не имеет значения, но это все более-менее конвертируется в скорость. Ну т.е. я думаю это вполне возможно увеличить скрытность за счёт скорости и наоборот, так что я не буду на этом зацикливаться, я всегда успее не согласиться с вашими выводами на счёт практической опасности. Так что я согласен и на такие условия главное что бы канал был двунаправленный.
Давайте продолжим здесь: https://habr.com/ru/post/560508/
покуда есть разделяемые ресурсы.
А если их нет? Я могу легко запретить доступ к любым разделяемым ресурсам. Более того, эпл это сама делает для своих системных демонов, засовывая их в песочницу, которая не позволяет делать вообще ничего, чего не нужно — нигде файл нельзя создать, никакой сокет нельзя открыть, никакой лишний API нельзя вызвать. Это делается ради сокращения поверхности атаки.
Тоже самое касается загрузки процессора. С чего вы решили, что процессу оно доступно? Мало того, что доступ к этому API можно запретить вручную. Так например на том же windows phone не было вообще API подобного у приложений.
Это уязвимость, потому что она позволяет обойти средства контроля доступа. Если я запретил любую возможность обмена информацией между двумя процессами, то этот механизм позволяет им обмениваться информацией в обход этих ограничений. Например, один процесс у меня пароли хранит, а в другом браузер. Я запретил первому любой доступ вообще куда либо, потому что там пароли лежат. А тут бац, приходит троянец, который умудряется попасть в мой суперзащищенный процесс и передает своему модулю в браузере информацию через этот канал для передачи в интернет. Уязвимость? Да. Без нее процесс с паролями был бы с беспомощным трояном внутри.
Не нужно недооценивать подобные вещи. Современные системы взламываются сложными цепочками уязвимостей, потому что каждый процесс имеет свои привилегии. Каждая подобная лазейка это возможность связать между собой эти уязвимости в практическую атаку.
А если их нет?
Но они всегда есть! Их нет, только когда у каждой программы свой собственный компьютер — со своим процессором, своей памятью и своей шиной.
Ну я же написал — загрузка процессора, например. Одно приложение загружает процесс в 100% или в 0% каждые 100ms. Второе мониторит загрузку процессора, например, запустив 100 потоков, которые делают чуть чуть работы и смотрят, сколько оно заняло реального времени. Есть нагрузка/нет регестрируется как последовательность битов. Далее вопрос в коррекции ошибок.
Т.е. вы никак эти каналы для передачи сообщений между двумя вирусами не уберете. Поэтому закрывать эту "уязвимость" с регистром и спать спокойно — большая ошибка. Система защиты должна предполагать, что все вирусы на машине могут между собой общатся. Всегда.
100% или в 0% каждые 100ms
Какую скорость передачи вы получите?
Заметит ли пользователь такую активность? Будет ли такая активность подозрительной? На сколько она подозрительней записи в регистр?
Скорость не так важна. Секретный пароль можно утащить и с скоростью 1 бит в минуту. Уязвимость от этого меньше не стала.
Можно загружать не на 100%, а на 50%. 99% пользователей не заметят. Обычно не мониторят диспетчер активности. Насколько это будет подозрительно если процесс "system service" жрет 50% cpu? Опять же, 99% не заметят.
А если их нет?
Значит, процессы исполняются на разных машинах. В пределах одной машины у вас всегда есть процессор (или несколько), память, и т.п.
Эта уязвимость полезна только для того, чтобы два вируса могли общаться друг с другом.
Автор m1racles на своем сайте опровергает все что вы написали. Можете как-то аргументировать свое сообщение? "Он обходит любые средства изоляции, потому что..., вот пруф..."
No. Correctly implemented hypervisors should disable guest accesses to this register by default, and this feature works correctly on the M1, which mitigates the issue. Both Hypervisor.framework (on macOS) and KVM (on Linux) do this, and are not affected.
1.Hypervisor.framework на данный момент единственный гипервизор работающий на m1.
2.Он доступ к этому регистру закрывает, следовательно все о чем писал товарищ выше - является 100% ложью.
Смысл вашего поста я вообще не особо понимаю. Смешно да, но никак не относится к нынешней ситуации. Почему - уже объяснил.
Если уязвимость в самом фреймворке то зачем вам m1racles, используйте ее и общайтесь в обход любым методом... Вы говорите нечто странное. Более того уязвимость в самом фреймворке закроют когда она обнаружится.
Далее, товарищ выше сказал: "Как я уже писал, процесс может находиться в песочнице и не иметь доступа ... а эта уязвимость дает ему такую возможность."
Дает ли данная уязвимость некий "доступ" в обход песочницы Hyper.Framework? Нет, не даёт. Значит все ваши сомнительные с точки здравого смысла заявления - не более чем фантазии.
Hypervisor.Framework не имеет никакого отношения к сэндбоксингу приложений.
Мартин в процитированном вами абзаце говорит только о том, что внутри правильно имплементированных виртуальных машин не будет доступа к этому регистру, поэтому:
— How can I protect myself?
— The only mitigation available to users is to run your entire OS as a VM.
Я удивлен тому, как вы распространяете ложную информацию и вам кто-то плюсует. Не нужно делать этого, заведомо ложная информация не есть хорошо
И возможно я кого-то разочарую, но итак существует несекретный способ легально пересылать данные между приложениями, игнорируя Sandbox в MacOS. Конечно отслеживаемый из расширений ядра, но кто сейчас их использует? А System Extensions отслеживают только самые распространенные операции.
одно нехорошее приложение крадет данные (не важно каким способом) и, чтоб не палиться сетевой активностью, передает украденные данные другому нехорошему приложению, которое маскируется под хорошее, для отправки данных во внешний мир.
Вы ставите одно приложение которое например красиво показывает загрузку процессора, или хранить пароли. Вы запрещаете ему любой доступ к любым ресурсам, кроме одного файла на диске.
Вы ставите другое приложение которое только и делает что отображает статус теста последнего коммита на github. Вы разрешаете ему только доступ на гитхаб. Вы не проверяете что оно отравляет, оно ведь только стучится на гитхаб и отображает статус и не имеет доступ к локальным ресурсам.
Никто не говорит что эта уязвимость большая, что эксплуатирую только её можно наделать много бед. Сама по себе она кажется бесполезной. Но т.к. она на аппаратном уровне, закрыть её пользователь самостоятельно никак не может.
Да, именно так. Но по внешним признакам совершенно не видно что это зловреды. каждый делает то что ему дозволено. Если бы этой уязвимости не было, повторить такое будет сложнее.
схема, когда у вируса две части, например, скрытый руткит/буткит/лоадер и «полезная нагрузка» (от майнера до клиента ботнета или шифровальщика), очень часто встречаетсяРазумеется. Но эти две части попадают в листы антивирусов одновременно.
помогла обойти, например, эвристические механизмы антивирусов,Не уверен, что использование какого-то узкоспециального регистра поможет обойти эвристические алгоритмы. Как бы не оказалось, что наоборот.
Однако взгляните например на CFNotificationCenterGetDarwinNotifyCenter, он проходит сквозь что угодно и совершенно легален.
Ну и наверняка доступ к нему тоже можно запретить в песочнице. Какой-нить системный демон запросто может быть ограничен, если ему не нужны эти уведомления.
Он не скрытый! В отличии от загрузки процессора или скорости доступа к памяти — это самый что ни на есть открытый канал. Этот регистр виден вообще всем в системе. Команды записи в этот ригистр видны в машинном коде. Можно хоть мониторить состояние регистра, хоть сканировать код программы на зепрещенную сигнатуру.
Тут многие пишут что уязвимость незначительная, но если сравнить со спектром, про который крик был на весь интернет, по-моему эта уязвимость критичнее, по крайней мере тут однозначно видно как это можно использовать и это довольно легко, хотя и количество сценариев явно ограничено.
Про meltdown я не говорю, meltdown в момем видении более серъезная проблема.
Просто у спектра мне сложно представить его реальное использование для взлома, а не теориетический пример, слишком специфичная проблема и я пока неслышал чтобы с помощью него что-то смогли взломать(поправьте меня если я ошибаюсь). Тут же по сути любой желабщий может воспользоваться, достаточно относительно базовых знаний.
Если сравнивать крупную уязвиомсть, но которую сложно использовать, или меньшую но которой точно может воспользоваться любой мне кажется что эта проблема серъезнее.
Хорошо что не в Рашке он живёт, а то бы присел за взлом. Может ещё и кибер-макруху повесели бы)
В "олимпиадном" программировании (там где надо написать программу для задачи которая проходит созданные автором задачи тесты) зачастую можно запустить программу в двух режимах: На публичных данных с получением результата/логов/итп, или на проверочных данных без получения такого результата на которых проходит итоговая проверка, чтобы нельзя было захардкодить решение.
Это пока единственный способ который я смог придумать как эксплуатировать данную уязвимость)
Регистр глобальный на кластер из 4 ядер. 2 процесса, исполняющиеся на разных ядрах могут передавать данные со скоростью в несколько мегабит в секунду.
Потеря 2 бит в миллисекунду останется вообще незамеченной.
А если поставить себе задачу надёжно писать в этот регистр чаще, то нужно целиком одно ядро процессора отдать на такой пишущий поток ядра ОС. И это должно быть производительное ядро, что в свою очередь приносит уменьшение производительности почти на четверть, и серьёзное увеличение энергопотребления в ненагруженном режиме работы.
Поправьте если заблуждаюсь, но кажется все эти уязвимости страшны либо если ты облачный ресурс создаешь где позволяешь изолированные процессы выполнять незнакомым людям, либо когда возникает уязвимость в браузере чтобы прямо через JS пробиться на локальный комп за пределы браузера и низкоуровнево выполнять процессорные инструкции…
В Apple M1 нашли уязвимость M1RACLES — возможна быстрая скрытая передача данных между приложениями