Basic Exploitation - Linux with Mitigations Disabled🦞

Weeks 1-5 (Basic Exploitation - Linux with Mitigations Disabled) of Exploit Development by AnotherOne@Pwn3rzs

Нашел довольно ценные заметки одного из участников канала Pwn3rzs, в канале люди бесплатно делятся материалами и знаниями об ИБ, в том числе есть множество заметок в Markdown формате, информация для меня довольно ценная, решил поделиться.

В сообщении разрешено распростарять эту информацию, значит со временем буду дополнять)

‼️Информация представлена исключительно в образовательных целях!

Первая CVE в ядре (write-up) ✔️

В октябре 2024 года мы с коллегой занимались фаззингом ядра Linux 6.11 в рамках выполнения работ для технологического центра. Хотя и основную работу сделал не я, в это время я в основном обучался этой теме, это было очень интересно, поэтому даже спустя время решил написать об этом чтобы оставить воспоминания :)

Как известно, крупные отечественные IT компании, использующие open source компоненты в составе своих продуктов, должны вносить определенный вклад по анализу и исправлению уязвимостей в них.

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

Одно ядро мы собрали с KASAN, другое с KMSAN. Поставили ядра на фаззинг и пустя некоторое время были найдены интересные краши в KMSAN сборке, в то время как в KASAN сборке мы так ничего стоящего не смогли найти - наверное потому что это самый популярный санитайзер)

1️⃣ BUG: KMSAN: uninit-value in selinux_inet_conn_request
Первый краш в KMSAN сборке мы нашли когда запустили debian сборку с ним в qemu/KVM. При подключении по ssh командой ssh root@127.0.0.1 -p 10021 -i ./bullseye.id_rsa возникает kernel panic. То есть чтение неинициализированного участка памяти в подсистеме SELinux. Проблему пофиксили бэкпортом патча из апстрима.

2️⃣BUG: KMSAN: uninit-value in tcp_v4_timewait_ack
Второй краш нашли когда попытались выполнить команду sudo apt install gdb 🙃 То же чтение неинициализированной переменной в сетевой подсистеме протокола TCP/IPv4. Так же бэкпортировали патч в апстриме.

Хотя эти краши и не были найдены методом фаззинга - в техцентре их нам засчитали.

3️⃣ BUG: KMSAN: kernel-infoleak in _copy_to_iter
Другой краш был уже интереснее - утечка неинициализированной памяти ядра через подсистему Netlink XFRM. Его как раз мы и нашли Syzkaller-ом. Несколько дней ушло на отладку и написание патчта. Затем еще пару недель переписок по почте, подготовки очередных версий патча, отправка патчей во все стабильные lvc-ветки техцентра, в upstream и stable. Благо, большую помощь с этим оказывал нам Фёдор Пчелкин.

В итоге, мейнтейнеры подсистемы XFRM приняли в upstream очередную версию патча, затем приняли бэкпорт и в stable-ветку ядра. А через некоторое время я увидел, что Linux kernel CVE assignment team присвоила этому исправлению CVE-2024-50110 с критичностью CVSS 3.1 5.5 - Medium. Как оказалось, любое security исправление в ядре всегда рассматривается серьезно и даже без PoC подобные исправления, как правило, получают CVE.

Это был классный опыт, сейчас я периодически занимаюсь фаззингом и кажется эта деятельность всё больше затягивает)

#kernel #cve #syzkaller #fuzzing

Deref of Null в интерпретаторе CPython 3.11+ 💥

Примерно полтора месяца назад я нашёл интересный баг в модуле sqlite3 стандартной библиотеки CPython. После сборки под статическим анализатором Svace и запуска анализа, Svacer подсветил маркер DEREF_OF_NULL.RET.LIB (CWE-476) в Modules/_sqlite/connection.c - возможное разыменование нулевого указателя cls. NULL может вернуть функция sqlite3_aggregate_context() несколькими строками выше. Причем после неё и так уже стоит

assert(cls != NULL);

Но, как известно assert() работает только в отладочных сборках, но не в релизе. Значит в релизе оно вполне может выстрелить, потому что по коду других причин почему это не может случиться я не нашел)

Далее я попытался понять каким образом могу вызвать выполнение этой строки, причем, чтобы пришел именно NULL после sqlite3_aggregate_context(). И, через некоторое время у меня был готов минимальный репродюсер:

import sqlite3

class A:
    def value(self):
        return 1

con = sqlite3.connect(":memory:")
con.create_window_function("f", 1, A)

con.execute("CREATE TABLE t(x)")
con.execute("INSERT INTO t VALUES (1)")

con.execute("""
    SELECT f(x)
    OVER (ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING)
    FROM t
""").fetchall()

Этот код, запущенный через REPL, роняет интерпретатор с SIGSEGV, у меня падает вот так:

zsh: segmentation fault (core dumped)  python3

Оценить критичность находки в тот момент было для меня затруднительно, но было понятно одно - данный баг может привести к DoS только в случае когда:
1. В скрипте регистрируется custom window function при работе с SQLite.
2. Скрипт позволяет внешнему пользователю управлять содержимым SQL запроса. То есть этот баг может использоваться только в цепочке эксплойтов. К примеру SQL-injection + этот DoS.

Поскольку, я не до конца понимал насколько вообще распространён код подобного вида в продакшене, на всякий случай решил этот баг отправить через приватный Security Advisories на GitHub. В результате переписки с мэйнтейнерами выяснилось что это обычный баг, он недостижиим извне - поэтому следующим шагом я создал публичный issue - в нем подробнее описаны технические детали. Даже хотел в ближайшее время заняться и исправить этот баг, но меня немного опередили)) Нашелся доброволец, который вроде как починил это через Claude Code😀, фикс пока на стадии ревью и вроде выглядит +- норм.

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

А ещё, мне кажется, находить подобные баги можно так же методом фаззинга самого интерпретатора CPython через кастомные мутаторы AFL++ на основе формальной грамматики python3, как нибудь попробую эту тему изучить.

#bug #python #svace #opensource