Бой курантов не за горами, а значит, самое время подвести итоги этого года.

Итак, самое главное: в этом году состоялся релиз нашего флагманского продукта - платформы для анализа файлов "Рекрипториум". Мы шли к этому не один год: создавали сильную команду реверсеров, аналитиков и ИИ-инженеров, формировали уникальную базу вредоносного и чистого ПО, позволяющую действительно качественно обучать наши модели ИИ и машинного обучения, проводили много исследований, прорабатывали микросервисную архитектуру, писали много кода. Эти работы продолжаются, интенсивность этих активностей растёт. Рекрипториум становится всё лучше и лучше, обеспечивая уже сейчас отличное качество анализа файлов. В том числе и без запуска в песочнице. А будет ещё лучше! Причём, те, кто покупают "Рекрипториум" сейчас, получат эти улучшения в качестве регулярных обновлений.

Совсем недавно сертификат ФСТЭК получил антивирус VRProtect для Linux 2.0.0. Мы рады тесному сотрудничеству с компанией "Вычислительные решения" и сопричастности развитию данного продукта. Дальше будет ещё лучше и интереснее!

Нам было бы сложнее проводить наши исследования в области ИИ без наших друзей и партнёров - компании HPC Park. Отличное железо, удобная и безотказная работа с контейнерами, отличная техподдержка! Облачная версия Рекрипториума использует GPU от HPC Park.

Особенно хочется выделить наши отношения с КФ МГТУ имени Н.Э. Баумана, откуда мы черпаем молодые кадры. Мы рады помогать друзьям и коллегам из Бауманки в их чрезвычайно полезных и интересных активностях. Обязательно продолжим это делать!

Друзья, поздравляем вас с Наступающим Новым годом! Счастья, успехов, процветания!

Новогодняя история или тайна CVE-2025-69277.

В день подготовки к празднованию Нового Года, а конкретно - 31.12.2025, была опубликована информация об уязвимости в супер-популярной криптографической библиотеке libsodium. Библиотека используется много где: в блокчейн-проектах (например, Monero, Stellar, ZCash), мессенджерах (например, в Signal и WhatsApp), IoT и т.д. Уязвимость связана с не совсем корректной проверкой принадлежности точки основной подгруппе точек эллиптической кривой.  Описание уязвимости есть по ссылке выше, плюс, в описании к патчу, предложенному моим старым другом и очень крутым специалистом в области эллиптической криптографии и блокчейн Олегом Тараскиным.

На этом месте начинается интересное. Олег, как и многие другие, использует libsodium в своих проектах. Т.к. эти проекты связаны, преимущественно, с финтехом, качеству реализации криптографических примитивов уделяется особое внимание - любое подозрительное поведение индуцирует детальный анализ. Так Олег наткнулся на вышеозначенную ошибку. Будучи человеком вежливым, деликатным и порядочным, он спросил мейнтейнера libsodium Фрэнка Дэниса, как лучше сообщить ему о проблеме с криптографией в его библиотеке. Не описывая саму проблему. Просто сказал, что проблема есть. Не сказал где. Просто запросил корректный способ сообщить о ней. На что получил сухой ответ с предложением сделать pull request. Случилось это 29 декабря ближе к вечеру. Однако уже на следующий день, буквально за несколько часов до патча Олега, вышел патч с исправлением уязвимости, о конкретике которой, подчеркну ещё раз, мейнтейнер не был уведомлен. Мало того, 30 декабря, т.е. буквально на следующий день, вышел вот этот подробный пост с разбором уязвимости. Не просто фикс кодовой базы, но ещё и весьма объёмное, но есть подозрение, что всё-таки довольно оптимистичное с точки зрения опасности, описание проблемы. И ни малейшего намёка на того, кто о проблеме сообщил.
Здесь, конечно, возникает много деликатных вопросов, основной из которых: а действительно ли мейнтейнеры libsodium не знали о проблеме?

#криптография

Свежее, вышедшее буквально вчера, описание многоступенчатый атаки с использованием уязвимостей VMware ESXi. Атака была обнаружена в декабре прошлого года. Там и BYOVD, и эксплуатация уязвимостей, и, как следствие, побег из виртуальной машины, и много ещё интересного.

Это ещё одно практическое подтверждение, что виртуализация не изолирует стопроцентно. Если что-то запускается в песочнице, то имеется вероятность побега из неё, используя, например, уязвимости виртуальной среды. Вот, к примеру, список уязвимостей Xen, используемой в том числе в ряде сетевых песочниц для анализа малвари. Например, в DRAKVUF, которая является донором для ряда продуктов.

#почитать #offensive

Ещё один пример, почему слепо доверять публичным опенсурсным библиотекам может быть крайне опасно. В мае 2025 года в npm-репозитории появился пакет "lotusbail", реализующий работу с API мессенджера WhatsApp (разрабатываемого экстремистской компанией Meta). Этот пакет выполнял все заявленные функции.👌 НО кроме того, содержал зловредную функциональность по перехвату сообщений, контактов, токенов аутентификации и привязке аккаунта жертвы к устройству атакующего. 🤷‍♂️

Зловредный пакет был доступен аж до 23 декабря. За это время его скачали около 60 000 раз. 😱

❓А теперь вопрос: учитывая, что использование готовых библиотек на каждый чих является сейчас best practice, института репутации разработчиков фактически нет (сплошные анонимы и ноунеймы), а вайб-кодинг становится все проще и эффективнее, что мешает таким кейсам становиться массовыми? Вполне вероятно, что вскоре зловредные форки библиотек будут плодиться одним запросом к LLM-ке. 🤔

@avleonovrus #lotusbail #npm #Nodejs #JavaScript #WhatsApp #Meta

Так и есть :)

Ранее мы обещали рассказать об обновлениях Рекрипториума. Платформа совершенствуется постоянно: обновляются базы, улучшаются модели и алгоритмы. Об этом мы, как правило, не пишем в канале. Однако есть особенные истории, которыми хочется делиться. Известно, что текстовые файлы, содержащие код на скриптовых языках, довольно плохо классифицируются антивирусами. Их модели и эвристики, ограниченные сверху мощностями пользовательских рабочих станций и устройств, просто не в состоянии решать эту задачу эффективно. Плюс, языков много, и под каждый нужно писать парсеры, формирующие векторы признаков для моделей. Непростая задача с учётом того, что всё это должно быть написано на компилируемых языках. Это же антивирус, а их не пишут на Python. Примерно полгода назад у меня возникла идея, которую я и озвучил на одном из совещаний: "А почему бы не попробовать обучить одну модель для нескольких языков?". Предпосылки к такому исследованию были: многие признаки вредоносности для многих языков плюс-минус схожи, как и признаки нормальности. Понятно, что оценка будет грубой, но насколько грубой? Сравнится ли такой подход с эвристиками антивирусов? Будет ли значимо лучше? Нужно было это проверить. В случае успеха экономия ресурсов налицо: вместо нескольких парсеров, эвристик и моделей можно получить один модуль. Экономия в разы. Однако у нас в Рекрипториуме уже на тот момент были все необходимые модели и алгоритмы как для быстрого анализа скриптов, так и для детального с использованием локальной LLM. Т.е. задача не была особо актуальной. Скорее, это была факультативная исследовательская задача. Как раз в тот момент к дипломному проекту на годовалых курсах по Data Science от МФТИ приближался один из наших ведущих сотрудников. Почему бы не совместить полезное с полезными и не предложить данную тему в качестве дипломного проекта? Первые результаты показали, что идея с полностью универсальной моделью даёт точность примерно на уровне антивирусов, что нас не особо устраивало. Однако выяснилось, что, если делать не полностью универсально, результат получается вполне приличным. В ходе исследования было испробовано много алгоритмов от разновидностей Random Forest до CodeBERT. В результате родились хорошие ИИ-классификаторы для Python, PHP и JS, превосходящие по качеству наши предыдущие. Они и вошли в недавнее обновление Рекрипториума. Причём, потенциал этих моделей не исчерпан и работа продолжается. Отметим, что речь идёт о быстрой классификации "на лету". Для детального анализа есть LLM.

#ии #рекрипториум

Project Zero опубликовали отличный свежий январский очень подробный разбор цепочки эксплоитов для CVE-2025-54957 и CVE-2025-36934, приводящей к компрометации Google Pixel 9 (взят в качестве примера). С повышениеи привилегий аж до ядра. Пикантности добавляет тот факт, что это zero-click-цепочка. Т.е. не требующая никакой реакции пользователя.
Уязвимости были пофикшены апдейтом от 5 января 2026 года. Разбор вышел 14 января. Читаем, учимся, наслаждаемся.
Раз.
Два.
Три.

#почитать #offensive #уязвимости

Использование LLM для автоматической генерации эксплоитов (AEG) ожидаемо набирает обороты. Очередной свежайший результат исследования на эту тему от Шона Хилана, который занимается этим довольно давно. Блогпост называется ни много ни мало "О грядущей индустриализации создания эксплойтов с помощью LLM". Несколько цитат:

я провёл эксперимент, в ходе которого создал агентов на основе Opus 4.5 и GPT-5.2, а затем предложил им написать эксплойты для уязвимости zeroday в интерпретаторе Javascript QuickJS. Я добавил различные современные средства защиты от эксплойтов, а также различные ограничения (например, предположение о неизвестном начальном состоянии кучи или запрет на использование жёстко заданных смещений в эксплойтах) и разные цели (запуск оболочки, запись файла, подключение к серверу управления и контроля). Агентам удалось создать более 40 различных эксплойтов для 6 разных сценариев, и GPT-5.2 справился со всеми сценариями. Opus 4.5 справился со всеми, кроме двух. Я опубликовал техническое описание экспериментов и их результатов на Github, а также код для воспроизведения экспериментов.

Сгенерированные эксплойты не демонстрируют новых, универсальных уязвимостей ни в одном из механизмов защиты. Они используют известные недостатки этих механизмов защиты и пробелы, существующие в их реальных реализациях. Это те же пробелы, которые используют разработчики эксплойтов, поскольку они, как правило, не придумывают новые способы обхода средств защиты от эксплойтов для каждого эксплойта. Я подробно описал эти пробелы здесь. Новизна присутствует в общих цепочках эксплойтов. Это верно по определению, поскольку уязвимость QuickJS была неизвестна до тех пор, пока я её не обнаружил (или, точнее, её обнаружил мой агент по поиску уязвимостей Opus 4.5). Подход, который GPT-5.2 использовал для решения самой сложной задачи, упомянутой выше, был для меня новым, и я не смог найти в интернете ни одного примера его применения. Однако я не удивлюсь, если он известен игрокам в CTF и профессиональным разработчикам эксплойтов, просто нигде не описан.

Мы уже достигли того уровня, когда с помощью обнаружения уязвимостей и разработки эксплойтов можно обменивать токены (прим. так мы платим за требуемой нам ресурс) на реальные результаты. Об этом свидетельствует проект Aardvark в OpenAI, где, по словам разработчиков, наблюдается такой результат: чем больше токенов вы тратите, тем больше ошибок находите и тем качественнее эти ошибки. Вы также можете увидеть это в моих экспериментах. По мере усложнения задач я мог тратить всё больше и больше токенов, чтобы продолжать находить решения. В конечном счёте ограничивающим фактором стал мой бюджет, а не модели. Я бы больше удивился, если бы это не было реализовано с помощью больших языковых моделей, чем если бы это было реализовано.

На данный момент, я думаю, у нас нет чёткого представления о реальных возможностях моделей текущего поколения. Причина в том, что оценки на основе CTF и оценки с использованием синтетических данных или старых уязвимостей не так информативны, когда речь идёт о поиске и использовании уязвимостей нулевого дня в сложных целях.

Подробности и код доступны на Github

#почитать #ии #offensive #уязвимости

Пишут, Роскомнадзор хочет фильтровать трафик с использованием ИИ. Мы не будем давать общих оценок этой и другим активностям данного ведомства, коих уже предостаточно в сети. Нам, как и всегда, интересна техническая сторона вопроса. Тема классификации сетевого трафика с помощью ИИ не является для нас новой, в 2021 году у нас был проект на эту тему. Речь шла о классификации в том числе и зашифрованного с помощью VPN трафика. Например, мы могли определить с высокой достоверностью, смотрит сидящий под VPN человек видео, "сёрфит", общается в чате или общается с использованием VoIP. Есть много разных алгоритмов и подходов: от совсем классических, использующих Random Forest и фиксированный набор признаков до более продвинутых, базирующихся на свёрточных нейронных сетях. Есть совсем современные и ресурсоёмкие подходы, базирующиеся, куда же без них, на трансформерах и LLM.

Однако, как мы не устаём повторять и в нашем канале, и вообще везде, главное - это данные. Их должно быть много, они должны быть разнообразными и сбалансированными. И, когда речь идёт о датасете, размеченными. Много качественных размеченных данных. Это ключевое. В задаче классификации сетевого трафика эти данные (дампы, по сути) должны быть собраны на разных устройствах, в разных сетевых сегментах, у разных провайдеров. В том числе поэтому мы очень скептически относимся к бравурным результатам академических исследований, когда трафик собирали в хорошем случае в лаборатории, а в плохом - выкачали из Интернета. Лучший и очень редкий случай - это, когда за данными идут туда, где они есть в нужных количествах. Случаев, когда есть и необходимые данные нужного качества, и компетентный опытный коллектив, умеющий с этими данными работать, крайне мало. Данные у РКН, подозреваем, есть :) Есть ли коллектив - не знаем :) Есть ещё важный момент: False Positives всегда будут. Поэтому, надеемся, что система на базе ИИ всё-таки не будет самостоятельно принимать решения о блокировках :)

Кстати, об открытых датасетах. Буквально вчера коллеги наткнулись на набор скриптов, помеченных, как вредоносные RAT. Их было штук 70. На поверку оказалось, что, примерно, 20 (!) из них чистые без намёка на вредоносность. Т.е. четверть. На такие истории мы натыкаемся постоянно. Кто-то обучает на таком и получает результаты. Иногда такие результаты идут в прод ;) Наша позиция по поводу антивирусных продуктов, включая песочницы, остаётся неизменной: нет вирлабы и системной работы по сбору качественных данных - нет качественного анализа в продукте. ИИ без данных не бывает.

Куда же такой длинные пост без картинки? :) В таблице результат работы нашего классификатора сетевого трафика пятилетней давности.

#ии #почитать

Всех студентов, Татьян и причастных поздравляем с Татьяниным днём! Знаем, сейчас у вас, будущие коллеги, несмотря на морозец за окном, тёплая сессионная пора. У кого-то прям горячая :) У кого-то сессия сдана и уже всё хорошо. Желаем успехов! Желаем вам неугасаемой жажды знаниий и сил и возможностей их получить! Учитесь сейчас, дальше это будет сильно дороже!

Ещё одно описание, как подключить локальную LLM (у автора Nvidia RTX 3090) к Ghidra. Здесь немного другой подход (более практичный, надо отметить) по сравнению с тем, который мы описывали ранее: вместо ручного написания промптов используется плагин GhidrAssist , содержащий необходимые промпты. Наиболее полезное применение: получение описания, что делает функция или ассемблерная инструкция. Т.е. эдакий ассистент реверсера. Есть возможность подключить RAG, что просто отлично. Полностью автоматизировать реверсинг не получится, но упростить и ускорить - вполне себе.

#ии #почитать #реверсинг

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

- Allocates memory with `VirtualAllocEx`, injects shellcode, and creates a **remote thread**
using `CreateRemoteThread`.

Здесь на самом деле решается немало интересных инженерных математически ёмких задач, основная из которых - работа с относительно небольшим контекстом без потери смысла.

Радует, что одним из основных участников этого развивающегося проекта является студент нашей Калужской Бауманки. Есть подозрение, что к диплому подойдёт с материалом на кандидатскую ;) Это один из плодов нашего тесного сотрудничества с КФ МГТУ.

#реверсинг #ии #рекрипториум

Телеграм гудит по поводу замедления Телеграм.

В зоне риска в том числе корпоративные коммуникации. Люди опасаются, что при использовании того же MAX их контент будет доступен третьим лицам, круг которых не совсем определён: от пресловутых товарищей майоров со своими целями и задачами до имеющих доступ к серверам IT-специалистов компании-вендора. Есть опасения, что это в итоге может быть использовано против абонентов таких мессенджеров и их компаний. Мы здесь все люди взрослые, а канал у нас технический. Поэтому эмоционально комментировать ситуацию с Телеграм мы не будем. Это всё при текущей архитектуре возможно? Вполне. Опасения понятны. Актуальны ли те же угрозы с Телеграм? Вполне.

А сейчас будет реклама :) Компания "Рекрипт" является партнёром компании "Анлимитед Продакшн" - компании-вендора поатформы корпоративных коммуникаций eXpress. eXpress давно и успешно используют ведущие российские компании. Мы тоже все корпоративные коммуникации, включая солидную часть партнёрских, давно затащили туда. Платформа полностью российская, надёжная и безопасная с массой возможностей, которые ещё более расширяются SmartApp-ами. Все данные находятся на доверенных серверах и надёжно защищены. Многие компании используют свои серверы для этих целей. Впрочем, есть разные варианты. Мы развёртываем платформу под ключ и имеем большой опыт в разработке SmartApps для eXpress. Не стоит доверять деловые коммуникации публичным мессенджерам. Это может быть чревато.
По вопросам приобретения и развёртывания обращайтесь к нам: contact@re-crypt.com

С 28 февраля по 2 марта будет проходить олимпиада CryptoFox-2026, организованная кафедрой №41 «Криптография и безопасность компьютерных систем» НИЯУ МИФИ и Институтом интеллектуальных кибернетическим систем НИЯУ МИФИ при участии кафедр «Информационная безопасность» МГТУ им Н.Э. Баумана и «Компьютерная безопасность и математические методы обработки информации» ЯрГУ им. П.Г. Демидова. Олимпиада посвящена 35-летию кафедры №41, выпустившей множество талантливых специалистов, некоторых из которых знаю лично и рад дружбе с ними. Мы - компания Рекрипт - считаем за честь быть партнёрами этого безусловно полезного мероприятия, развивающего нашу российскую математическую и инженерную школу. Всем участникам удачи!

#криптография

Человек подружил бесплатную IDA Free с LLM, портировав плагин ida-pro-mcp на C++. IDAPython требует платной версии IDA, а у бесплатной IDA есть C/C++ SDK. Как сейчас принято (де-факто уже стандарт в разработке), портирование человек реализовывал не самостоятельно, а завайбкодил с помощью Claude. Пишет, работает.

#реверсинг #ии

Наш Рекрипториум в Реестре российского ПО. Ура!

#рекрипториум #ии

Вышла Voicebox - опенсорсная система для клонирования голоса. Ядро системы - локально развёрнутая LLM Qwen3-TTS.
Пранки и прочие подобные веши постепенно выходят на новый уровень.

#ии

Что почитать на выходных и в свободное время вместо бездумного и безумного убивающего мозг и нервы чтения новостных лент и унылой пафосной банальщины от надутых экспертов по всему?

Например, вышла новая книга Сергея Игоревича Николенко про машинное обучение. Это не первая его книга про ИИ, но все их объединяет взгляд на машинное обучения с точки зрения теории вероятности и математической статистики. Байесовский подход, который красной нитью пролегает по всем главам книги, позволяет понять саму суть машинного обучения. Понять не только как, но, самое главное, почему. В этой книге всё, на мой взгляд, последовательнее и подробнее. Рекомендую.

Есть и другие книги, делающие акцент на вероятностном подходе. Пожалуй, самая известная - "Вероятностное машинное обучение" Кевина Мерфи. Она есть на русском, но перевод так себе. Лучше читать в оригинале.

Так что пока на русском, на мой взгляд, это лучшая книга по теме.

Ну и котики там есть :)

#ии #почитать

Поздравляем с Днём Защитника Отечества всех, кто защищает Родину в эти нелёгкие времена! А также всех тех, кто на разных участках работает над укреплением и усилением научного, промышленного, экономического, военного потенциала России. Взгляды и оценки событий могут быть разными, но Отечество у нас одно! Не будем забывать об этом. С Праздником, друзья и коллеги!

Уважаемый коллега и подписчик нашего канала предложил осветить технологический стек Capability Hardware Enhanced RISC Instructions (CHERI). Не великий секрет, что компанию "Рекрипт" основали в 2013 году люди, имеющие отношение к реверсингу, обфускации и деобфускации, компиляторным технологиям. Долгое время одним из источников дохода компании были именно компиляторные технологии, да и сейчас мы активно используем накопленные опыт и знания в ряде проектов, включая платформу для анализа файлов "Рекрипториум". Потому тема нам близка и интересна.

Не сказать, что CHERI - это совсем новое слово в безопасности. Подробности об архитектуре можно прочитать в этом документе, но давайте пока отложим его в сторону и крупными мазками вспомним, как решаются сейчас проблемы переполнения стека и кучи, use-after-free, разделения доступа к памяти в компилируемых языках. Например, в C/C++.

Если говорить про стек, то это прежде всего canaries - сгенерированные на этапе компиляции значения, которые помещаются в стек, как локальные переменные, в начале функции, а при выходе из функции эти значения проверяются и, если нет совпадения, то генерируется exception. Тут же всплывает идея сделать отдельный стек для переменных и другой - для адресов возврата. Идея не нова и реализована на аппаратной уровне, например, в том самом российском процессоре "Эльбрус". Понятно, что на уровне базовой VLIW-архитектуры, а не в режиме совместимости. Он вообще с точки зрения безопасности архитектурно довольно интересен и проработан, но это тема для отдельного поста, минимум.

От переполнения кучи в базовом варианте защищаются с помощью ASLR и DEP (с использованием NX-бита), маркеров, проверки целостности и разнообразных прочих mitigations. Те же mitigations частично защищают от use-after-free.
Есть ещё умные указатели, менеджеры памяти с счётчиками, подходы а-ля TailCheck с встраиванием механизмов защиты на этапе компиляции и сборки (LLVM, конечно же, куда без неё). Подходы к встраиванию разного рода защиты с использованием LLVM достаточно логичны и популярны. Мы сами довольно продолжительное время разрабатывали заказные решения на базе LLVM, повышая защищённость софта, компилируемого с помощью нашего решения. Кстати говоря, CHERI ожидаемо базируется на LLVM весьма плотно.

Помимо этого, есть масса mitigation tools, не требующих наличия исходного кода. Они работают проактивно, выявляя подозрительное поведение процесса. Их можно встретить, например, в антивирусных продуктах. В составе ОС тоже есть. Например, у Microsoft была такая штука - EMET (Enhanced Mitigation Experience Toolkit), часть функций которой перекочевала в последние версии Windows (ProcessMitigations, Windows Defender Exploit Guard).

Вернёмся к CHERI. Указатели в языках C и C++ - это краеугольный камень. Особенно - в C. Можно ли от них отказаться и заменить какими-то другими конструкциями (какими-то описателями, содержащими помимо адреса ещё какую-то информацию) софтверно в рамках одного программного модуля? В принципе, да. Но будут понятные особенности взаимодействия с внешними компонентами, в которых такой замены не производилось, во-первых. Например, всякие API, на которые нужно делать обёртки. Во-вторых, это, по сути, свой менеджер памяти, который громоздок и скорости явно не прибавит. Причём, это уже не будет классический C\C++, ибо разработчику для реализации придётся использовать некоторые расширения в каком-то виде (типа каких-нибудь intrinsics или классов или просто API). Это в-третьих. Короче, так можно изобрести какой-нибудь .Net Framework или что-то в этом духе. Можно, конечно, пойти дальше, и такую конструкцию распространить на всю систему, но, как минимум, одна проблема останется: это будет очень медленно работать. Это как всю ОС на условный .Net Framework перевести. C\C++ - это языки системного программирования. Код должен быть быстрым, эффективным, не ресурсоёмким. Да и к безопасности этой конструкции есть вопросы, ибо она чисто софтверная.
Всё начинает играть новыми красками, если к софтверным возможностям добавить аппаратные - на уровне архитектуры процессора добавить возможность работы с расширенной конструкцией указателя. В CHERI используются указатели двойного размера и называются не указателями, а capability. Например, для 64-х битной архитектуры размер capability составит 128 бит. Половина такого указателя - это адрес, как и раньше. Другая половина - дополнительная информация: границы (bounds), разрешения или права (permissions), тип объекта (к примеру, код или данные), флаги (служебные флаги). Память в архитектуре CHERI является тегированной, поэтому просто взять, и поменять поля в структуре capability не получится. Есть такая очень важная штука для каждого capability - тег Validity. Доступ к нему есть только у процессора, хранится он отдельно. При попытке модификации (например, перезапись) capability превращается в обычную структуру данных (тег сбрасывается), а значит, использование этого указателя в качестве указателя дальше невозможно.
Что насчёт use-after-free? При освобождении памяти все теги Validity для указателей (capabilities) сбрасываются, а значит, пользоваться этими указателями будет невозможно. Т.е. происходит эдакий отзыв указателей. Это существенно усложняет эксплуатацию уязвимостей use-after-free.

Что в сухом остатке? Архитектура интересная и, судя по открытым источникам, действительно усиливающая безопасность. Есть чипы, её поддерживающие (Arm Neoverse N1). Есть проект по адапатации концепции CHERI для IoT (CHERIoT) от Microsoft. Т.е. желание и возможности расширять влияние этой концепции тоже есть. Основной минус - софт придётся рефакторить и пересобирать. Хоть и утверждается, что "оно, преимущественно, само" (для больших кодовых баз (миллионы строк кода) требуется изменить лишь 0.026% строк), но мы точно знаем, как оно бывает в жизни. Для упрощения рефакторинга есть компилятор CHERI LLVM. Но он всё-таки не совсем идентичен gcc, а значит, могут быть нюансы. При этом поддерживать CHERI должен весь софт от ОС до последнего пользовательского приложения: никакого режима совместимости (здесь capabilities, а здесь обычные указатели) нет. Из ОС там только FreeBSD. Здесь напрашивается, конечно, вариант с отдельным CHERI-ядром для чувствительных программных компонент.

Есть ли будущее? Определённо да. Захватит ли CHERI-концепция мир? Если и да, то очень не скоро. Зоопарк экосистем огромен и растёт. Это очень сложно отрефакторить и портировать на новую архитектуру. Впрочем, как будут продвигать. Посмотрим.

#почитать