Skip to content
KitploitKITPLOIT
ИнструментыЭксплойтыБлог
Log in
Отправить
ИнструментыЭксплойтыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

ЛентыКонтактыКонфиденциальность© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
Инструменты/GitHubGitHub/zanezhub/cve-2022-1015-1016
Повышение привилегийАнализ уязвимостейЭксплуатацияОбучение и ОбразованиеЭксплуатация Бинарных Файлов
GitHubzanezhub/cve-2022-1015-1016

CVE-2022-1015-1016

Перевод на испанский язык CVE-2022-1015 и 1016, обнаруженных и задокументированных Дэвидом.

РепозиторийСайт
164 лет назадЕщё не проверено

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться

CVE-2022-1015 и CVE-2022-1026

Этот README.md является переводом блога Дэвида. Дэвид обнаружил CVE-1015 и CVE-1016 в ядре Linux. Вы можете посетить его веб-сайт, чтобы прочитать оригинальный документ.

Вот его социальные сети:

  • Twitter
  • Github

Анализ двух новых уязвимостей Linux в nf_tables

Опубликовано 2 апреля 2022 года.

  • CVE-2022-1015 позволяет выполнить доступ за пределами границ (out-of-bounds), вызванный недостаточной проверкой входных аргументов, что может привести к удалённому выполнению кода и локальному повышению привилегий.
  • CVE-2022-1016 связан с плохой инициализацией переменных, размещённых в стеке, что может быть использовано для утечки большого разнообразия данных ядра в пространство пользователя (userspace).

Эти проблемы должны быть эксплуатируемыми в конфигурациях по умолчанию самой новой версии Ubuntu и RHEL. Я написал свою Proof of Concept (PoC) для CVE-2022-1015, нацелившись на версию ядра 5.16-rc3 от Arch Linux.

Этот документ предназначен для людей, обладающих базовыми знаниями о ядре Linux с точки зрения функциональности и безопасности. Я постарался сделать этот документ дружелюбным для людей, не имеющих знаний о сетевом стеке, чтобы сделать его доступным для широкой аудитории.

Вот руководство по чтению:

  • Если вы здесь просто для того, чтобы почитать об уязвимости, начните с Раздела 4.
  • Если вы также хотите немного контекста о подсистеме ядра, начните с Раздела 2.
  • Если вам интересен ещё больший контекст, прочитайте весь документ.

1. Контекст

В середине февраля программа безопасности Google объявила о продолжении своей программы вознаграждений kCTF, предлагая награды от $31,337 до 91,337 долларов за эксплойт в ядре Linux, способный повысить привилегии до пользователя root из непривилегированных процессов в песочнице nsjail.

Будучи бедным студентом, это, очевидно, привлекло моё внимание. Это был мой первый поиск уязвимости в «реальном мире», но в своих приключениях с CTF со своей командой я ознакомился с ядром Linux с точки зрения безопасности. После долгих часов с очень малым, близким к нулю прогрессом (но с большим знанием о Linux), мне удалось найти некоторые уязвимости в модуле nf_tables.

К сожалению, в конечном итоге я понял, что этот модуль не был включён в правила kCTF от Google (поэтому я не получил никакого вознаграждения за эти две уязвимости). Но, очевидно, я всё равно сообщил о них и написал эксплойт LPE (локальное повышение привилегий) для CVE-2022-1015.

1.1 Определение цели и стратегия аудита

Итак, вы решили, что найдёте несколько уязвимостей в Linux. Что теперь? Linux — это огромный проект, и довольно легко не увидеть лес за деревьями (вы так сосредотачиваетесь на деталях, что теряете общее видение ситуации). Что ещё хуже, многие части не документированы, и вам нужно прочитать много кода, чтобы понять, что происходит.

Я начал с попытки получить детальное представление о модели безопасности Linux. Найти баг — это одно; но найти хороший баг — совсем другое. В конце концов, не все баги созданы равными:

  • Если баг требует привилегий root, то не существует значимого ограничения безопасности (если только не включена подпись модулей ядра).
    • Некоторые вещи, которые приходят мне на ум, — это многие модули (виртуальных) файловых систем. Только изначальный пользователь root может монтировать эти файловые системы. Исключением является vfs, где указано FS_USERNS_MOUNT; в этом случае вы можете монтировать их в пространстве имён пользователя.
  • Если к багу нельзя получить доступ через системные вызовы, он, вероятно, не будет эксплуатируемым.
    • Это относится ко многим драйверам оборудования, поскольку у вас нет физического доступа к машине. Низкоуровневые сетевые драйверы всё ещё могут быть хорошей целью, если вы можете, например, отправлять данные через Bluetooth или 802.11.ac.
    • Очевидно, это зависит от сценария, в котором вы находитесь.
  • Многие баги требуют CAP_SYS_ADMIN или CAP_NET_ADMIN.
    • Пространства имён пользователей включены по умолчанию, так что это не проблема.
    • В противном случае сначала вам придётся повысить привилегии до root в пространстве имён пользователя внутри контейнера.
  • Не все модули будут присутствовать на вашей цели.
    • Linux — это исключительно хорошо настраиваемый программный продукт, поэтому все конфигурации могут различаться множеством способов.
    • К конфигурации ядра обычно можно получить доступ через /proc/config.gz. Модули могут быть загружаемыми (=m) или скомпилированными отдельно и загружаемыми во время выполнения (=y).
    • Вы можете использовать /proc/modules и /proc/kallsyms, но они не всегда надёжны, поскольку модули могут динамически загружаться в ядро (например, request_module).
    • Если вы не уверены, напишите небольшую программу, которая попытается взаимодействовать с модулем.

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

Я уже извлёк урок из предыдущего пункта. Как я упоминал, модуль nf_tables не был загружен в экземпляре, предоставленном kCTF. Я мог бы понять это с самого начала и избавить себя от разочарования :p. С другой стороны, вероятно, вы не читали бы этот блог сейчас, если бы я понял это раньше; думаю, в конце концов всё сложилось хорошо.

Объяснение того, почему COS, форк Linux от Google, оптимизированный для контейнеров, не имел nf_tables, можно найти здесь и здесь.

1.2 nf_tables: почему?

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

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

Я исследовал множество сетевых файловых систем, но не нашёл ничего важного. После навигации по подкаталогу net/ я наткнулся на модуль nf_tables. Он показался мне немного сложным, поэтому я решил потратить время на его изучение.

2. Введение в netfilter

Netfilter (net/netfilter) — довольно большая подсистема сетевых файлов в ядре. Вкратце, netfilter размещает хуки через сетевые модули, в которых другие модули могут регистрировать обработчики. Когда достигается хук, управление передаётся этим обработчикам, и они могут работать со своей соответствующей структурой сетевых пакетов. Обработчики могут принимать, отбрасывать и изменять пакеты.


4. CVE-2022-1015

Скачать инструмент