Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Emacs продемонстрировали сразу две тенденции: устойчивость классических ошибок в низкоуровневом коде и всё более заметную роль ИИ в поиске и эксплуатации багов.
Уязвимость в FreeBSD: код на уровне ядра через NFS
В операционной системе FreeBSD была устранена критическая уязвимость CVE-2026-4747, позволявшая добиться удалённого выполнения кода в контексте ядра, то есть с максимальными привилегиями. Атаке подвержены NFS-серверы и приложения, выступающие RPC-серверами и использующие библиотеку librpcgss_sec.
Корень проблемы находился в модуле ядра `kgssapi.ko`, реализующем поддержку протокола RPCSEC_GSS. Этот протокол базируется на API GSS (Generic Security Services) и применяется для создания защищённых, аутентифицированных каналов связи, в частности - для организации безопасного доступа к NFS по Sun RPC с использованием Kerberos и шифрования трафика.
Ошибка заключалась в некорректной обработке данных при проверке подписи: содержимое сетевого пакета копировалось в буфер фиксированного размера без должной валидации длины. В результате возникало классическое переполнение буфера, открывающее путь к выполнению произвольного кода на уровне ядра. Важно, что баг срабатывал ещё до успешного прохождения аутентификации, то есть злоумышленнику достаточно иметь возможность отправлять специально сформированные NFS-пакеты на уязвимый сервер.
Уязвимость затрагивала не только ядро: любое пользовательское приложение, работающее как RPC-сервер и использующее `librpcgss_sec`, также потенциально становилось точкой входа для атаки. При этом такие сервисы могут поставляться сторонними разработчиками и не входят в базовую систему FreeBSD, что усложняет оценку реального периметра уязвимых конфигураций.
Для данной ошибки опубликован рабочий эксплоит, позволяющий удалённо запустить `/bin/sh` с правами root. Это подчёркивает максимальную критичность проблемы: при успешной эксплуатации атакующий фактически получает полный контроль над системой.
Роль ИИ в обнаружении и эксплуатации бага FreeBSD
Интересной особенностью этого инцидента стало то, что уязвимость была выявлена сотрудником компании Anthropic с помощью ИИ-ассистента Claude. Более того, исследователи из команды Calif смогли использовать ту же модель не только для анализа отчёта об уязвимости, но и для автоматизированной разработки рабочего эксплоита.
Модели была передана лишь общая информация, опубликованная проектом FreeBSD: описание бага без детализированного PoC. На основе этих данных Claude:
- восстановил уязвимый сценарий;
- развернул виртуальную машину с соответствующей конфигурацией FreeBSD;
- настроил удалённую отладку и анализ дампов ядра;
- сгенерировал эксплоит, добившийся выполнения кода в ядре;
- интегрировал в эксплоит запуск `/bin/sh` с root-привилегиями.
По данным исследователей, на создание эксплоита ушло около четырёх часов работы модели. Этот эксперимент показал, что современные ИИ-инструменты уже сейчас способны закрывать полный цикл: от понимания уязвимости по высокоуровневому описанию до получения практически применимого кода атаки.
Поиск 0‑day в Vim и Emacs с помощью ИИ
Исследователи не остановились на FreeBSD и проверили, насколько легко ИИ способен находить новые, ранее не описанные уязвимости в популярных приложениях. В качестве целей были выбраны текстовые редакторы Vim и GNU Emacs - программы, которые традиционно устанавливаются на большом количестве серверов и рабочих станций разработчиков и администраторов.
Показательно, что промпты к модели были крайне простыми: в духе "найди 0‑day уязвимость в Vim, возникающую при открытии файла". Несмотря на такую примитивную постановку задачи, Claude сумел указать на реальные, до этого неизвестные проблемы, позволяющие исполнить произвольный код при открытии специально подготовленного файла в редакторе.
Так ИИ фактически выступил в роли автоматизированного исследователя по безопасности, проводящего целевую ревизию кода и конфигураций с прицелом на эксплуатацию.
Уязвимость в Vim: обход sandbox через modeline
Обнаруженная в Vim уязвимость получила идентификатор CVE-2026-34714. Она связана с механизмом `modeline`, который по умолчанию включён (`:set modeline`) и позволяет задавать настройки редактирования прямо внутри обрабатываемого файла. Например, через специальные строки в конце документа можно менять отступы, кодировку и другие параметры локально для этого файла.
Изначально разработчики Vim ограничили список опций, доступных из modeline, и предусмотрели исполнение выражений в безопасном "песочном" режиме (sandbox). Такой подход должен был не допустить выполнения потенциально опасных конструкций при простом открытии файла.
Проблема возникла вокруг опции `tabpanel`. Для неё не был установлен флаг `P_MLE`, из-за чего внутри параметра разрешалось использовать выражение вида `%{expr}`, выполняемое без активации режима `modelineexpr`. Это открывало возможность выполнения более сложных конструкций, чем предполагалось, и становилось первым шагом к обходу изоляции.
Дальнейшая эскалация строилась на недоработке функции `autocmd_add()`, которая отвечает за создание автокоманд. При привязке действия к событию `SafeStateAgain` в ней отсутствовали достаточные проверки безопасности. В результате можно было спланировать выполнение произвольной команды уже после выхода из sandbox, то есть фактически вырваться из ограниченной среды.
Уязвимость была устранена в релизе Vim версии 9.2.0272. До обновления достаточно было открыть файл, содержащий специально сформированную директиву в modeline, чтобы редактор выполнил команду, например, запуск утилиты `id` с перенаправлением результата в произвольный файл в каталоге `/tmp`.
Уязвимость в Emacs: опасные побочные эффекты Git-интеграции
В GNU Emacs проблема носит иной характер и связана с интеграцией с системами контроля версий. При открытии файла в каталоге, в котором есть подкаталог `.git/`, Emacs автоматически выполняет команды `git ls-files` и `git status`, ориентируясь на содержимое этого репозитория. Это делается для удобства пользователя: подсветка изменений, информация о статусе файла и прочий функционал.
Однако такой подход означает, что редактор добровольно запускает команды Git, руководствуясь конфигурацией самого репозитория. Для атаки достаточно, чтобы в `.git/config` была прописана опция `core.fsmonitor`, указывающая на произвольную команду, подставленную злоумышленником. Как только Emacs вызовет Git в таком репозитории, указанная команда будет выполнена.
Важный момент: жертве не нужно выполнять никаких особых действий - достаточно открыть файл из каталога, где уже лежит подготовленный `.git/` с нужной конфигурацией. Для сценариев "атаки через файловую систему" это крайне удобный вектор: архив или директория с проектом кажутся обычными, а опасность скрывается в конфиге Git.
Сопровождающие GNU Emacs отказались признавать это именно проблемой редактора. Их позиция в том, что такая возможность вытекает из работы Git и его конфигурационных опций, а Emacs лишь запускает стандартные команды. Фактически ответственность перекладывается на сам Git и на администратора, который использует подобную конфигурацию.
Почему такие баги до сих пор появляются
Источником описанных уязвимостей становятся одни и те же классы ошибок, которые наблюдаются в индустрии уже десятилетиями:
- переполнение буферов и недостаточная проверка длины данных (случай FreeBSD);
- недооценка влияния "удобных" механизмов настройки из файлов пользователя (Vim modeline, Emacs + Git);
- сложные цепочки логики, где один модуль предполагает ограничения, которые другой не соблюдает (sandbox в Vim против `autocmd_add`);
- доверие к внешним инструментам и конфигурациям (Emacs и Git).
Несмотря на годы развития, строгие руководства по безопасности и накопленный опыт, практика показывает: достаточно небольшого изъяна в проверках, чтобы в привычной функции - аутентификация, удобные настройки, интеграция с VCS - образовался полноценный вектор атаки.
Как ИИ меняет безопасность: ускоритель и для защитников, и для атакующих
История с FreeBSD, Vim и Emacs демонстрирует, что ИИ перестаёт быть просто инструментом для автоматизации рутинных задач. Он уже умеет:
- анализировать сложный низкоуровневый код и протоколы;
- выстраивать гипотезы о возможных точках переполнения, ошибок логики и нарушений инвариантов;
- предлагать варианты эксплуатации и проверять их на практике в виртуальной среде;
- писать вспомогательную инфраструктуру - скрипты для отладки, подготовки окружения, обработки дампов.
Для команды, занимающейся безопасностью, это мощный усилитель: можно охватывать больше кода, быстрее проверять патчи, моделировать атаки. Но та же самая способность доступна и злоумышленникам, что радикально сокращает время между появлением бага и созданием эксплоита.
В результате растёт значимость:
- быстрой реакции на отчёты об уязвимостях;
- автоматизации тестирования и анализа кода со стороны самих разработчиков;
- внедрения безопасных языков и инструментов (анализаторы, санитайзеры, строгие политики компиляторов).
Что стоит учесть администраторам и разработчикам
Для практиков из этой истории следуют несколько прямых выводов:
1. Обновления критичны. FreeBSD-системы, использующие NFS и RPCSEC_GSS, необходимо оперативно обновлять. То же касается Vim (до версии, где закрыта CVE-2026-34714) и Emacs в сочетании с Git, хотя там часть риска перекладывается на конфигурацию.
2. Ограничение функционала по умолчанию. Механизмы вроде `modeline`, автокоманд, автоматического запуска внешних команд (Git, системные утилиты) должны рассматриваться как потенциально опасные и по возможности быть отключены или ужесточены в средах с высокими требованиями безопасности.
3. Изоляция и минимизация доверия. NFS-серверы, RPC-службы и редакторы, работающие с непроверенными файлами, должны запускаться в максимально изолированных условиях: контейнеры, отдельные учётные записи без избыточных привилегий, строгие сетевые политики.
4. Использование ИИ как инструмента защиты. Теми же методами, которыми ИИ помогает находить уязвимости исследователям, могут и должны пользоваться разработчики: для аудита унаследованного кода, анализа новых патчей, поиска опасных шаблонов вроде небезопасных копирований в буферы.
5. Пересмотр старого кода. Модули, написанные много лет назад, особенно на Си и C-подобных языках, должны рассматриваться как зону повышенного риска. Именно там чаще всего скрываются классические ошибки, которые ИИ умеет отыскивать всё лучше.
Итог
Случай с удалённым исполнением кода в ядре FreeBSD и эксплойтами для Vim и Emacs показывает сразу несколько тенденций: старые уязвимости остаются с нами, популярные инструменты разработчиков могут становиться точкой входа для атак, а ИИ уже сейчас способен ускорять и поиск багов, и создание эксплоитов. В этих условиях единственный устойчивый ответ - системный подход к безопасности, регулярные обновления, минимизация доверия к "умным" функциям по умолчанию и активное использование тех же ИИ-инструментов для защиты, а не только в качестве любопытного эксперимента.
