Welcome 👋🏻

Привет, меня зовут Пётр, я занимаюсь разработкой с 2022 года, интересуюсь сетями и информационной безопасностью.

Давно уже хотел начать делиться своими мыслями в сфере Application Security и наконец-то буду это делать тут!

Особенно интересны для меня темы - фаззинг и статический анализ, нахождение уязвимостей.

Такой опыт для меня новый и самому пока не ясно как у меня всё это будет получаться)

Подписывайся и будем проходить этот путь вместе ☺️

Удаление русских разработчиков из ядра Linux (open-source)

Грег Кроа-Хартман (Greg Kroah-Hartman), отвечающий за поддержку стабильной ветки ядра Linux, внёс изменение в список мэйнейнеров ядра Linux, в результате которого были удалены 11 разработчиков, предположительно работающих в РОССИЙСКИХ компаниях. В качестве причины удаления упомянуто лишь "выполнение различных требований комплаенса". Так же отмечено, что разработчики могут быть возвращены в список мэйнтейнеров в случае предоставления определённой документации.

Сказать что для меня это было неожиданно?) Это скорее тупой и некрасивый поступок, удалили просто список разработчиков, принимавших участие в разработке ядра Linux, хотя код который они написали оставлен.

"выполнение различных требований комплаенса"

И это пишет разработчик, человек, привыкший к точным формулировкам и требующий их от всех остальных. Сказано как будто на языке российских политиков.

какой документации?
нарушение каких требований?
что за самодурство такое?

Сюр ещё в том, что многие вещи, которые изначально принципиально создавались в open-source "свободными", типо ядра Linux, многих блокченов
(USDT или Tether к примеру) по сути подчиняются санкциям и не децентрализованы.

Думаю если политика будет влиять на ядро Linux, ничего хорошего из этого не выйдет, нельзя нарушать сами принципы open-source, иначе он перестанет быть open ☺️

Подробнее почитать можно тут:
https://www.opennet.ru/opennews/art.shtml?num=62090

Оригинальный коммит:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6e90b675cf942e50c70e8394dfb5862975c3b3b2

#Linux #kernel

Integer Overflow в syslog-ng 👩‍💻

Фаззил, значит, я однажды syslog-ng фаззером AFL++ и нашёл такой краш:

* thread #2, name = 'syslog-ng', stop reason = signal SIGILL: illegal instruction operand

Исполняемый файл собирал компилятором afl-clang-lto с санитайзерами ASAN и UBSAN. Врезки под фаззинг запускались в persistent-mode в несколько инстансов параллельно с разными стратегиями мутации (explore, coe, mmopt,...). Сам фаззинг как обычно длился около суток, с более 1 млн запусков в каждом инстансе.

Далее начал разбираться, выяснилось, что я не первый наткнулся на этот баг, ему уже было около 4-х лет 😲
Пересобрал бинари компилятором gcc с отладочной информацией, без оптимизации, без санитайзеров и пошёл дебажить)
Под отладчиком gdb давай запускать эту врезку с файлом, вызвавшим падение (благо был backtrace). Поставил в нужных местах точки останова, но падения не произошло, зато CF флаг процессора говорил о переполнении целого.

В итоге: при чтении своего конфига syslog-ng итерпретирует строку вида:

<4444444444444444444<4\xbe\xbe\xbe\xbe\xbe\xbe\xbe\xbe\xbe

И, не находя закрывающую > , пишет это огромное число в переменную int, это и вызывает SIGILL в итоге.

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

Так, я впервые пофиксил баг в upstream, было интересно ☺️

Ссылка на pull request:
https://github.com/syslog-ng/syslog-ng/pull/5254

#fuzz

Впервые участвовал в Tinkoff-CTF на этих выходных 💳

Скажу одно - было интересно и сложно одновременно 🙃

- Лига безопасности
- Заняли 329/977 место
- 3 человека в команде
- Решено 3/30 задачи ✏️
- Так и не решил задачу про aiogram бота
- Приобретено МНОГО новых скиллов)

Самое интересное задание было на отладку удалённо компилируемого сишного кода, жду разбора заданий!

t-ctf.ru/share/S6NeXwdx

💥 Syzkaller - Linux 6.16 с KASAN - Часть 1

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

Ниже опишу свой опыт сборки ядра 6.16 из ветки linux-next с санитайзером KASAN и запуском фаззера Syzkaller.
Кому интересно - добро пожаловать под кат🤓

1️⃣ Сборка ядра с KASAN
Решил выбрать самое свежее ядро что есть на данный момент - это "экспериментальная" dev-ветка linux-next, она используется как интеграционная для обкатки самых новых драйверов пред вливанием в mainline ветку, часто содержит регрессии производительности и баги. Её и будем фаззить!
- Подготовка к запуску сборки:

git clone https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
cd linux-next
sudo dnf builddep -y kernel

- Включаем нужные подсистемы и функции ядра и собираем:

# полная очистка
make mrproper

# генерация стандартного конфига
make ARCH=x86_64 defconfig

# <-- config from https://portal.linuxtesting.ru/LVCFuzzingKernelOptions.html#main

# включаем namespaces
scripts/config -e CONFIG_NAMESPACES \
    -e CONFIG_UTS_NS \
    -e CONFIG_IPC_NS \
    -e CONFIG_PID_NS \
    -e CONFIG_NET_NS \
    -e CONFIG_USER_NS \
    -e CONFIG_CGROUP_PIDS \
    -e CONFIG_MEMCG

# Поддержка USB
scripts/config -e CONFIG_USB \
               -e CONFIG_USB_GADGET \
               -e CONFIG_USB_LIBCOMPOSITE

# Поддержка Bluetooth
scripts/config -e CONFIG_BT \
               -e CONFIG_BT_BREDR

# Поддержка IEEE 802.15.4
scripts/config -e CONFIG_IEEE802154 \
               -e CONFIG_IEEE802154_6LOWPAN \
               -e CONFIG_MAC802154 \
               -e CONFIG_MAC802154_HWSIM

# Чтобы отобразить покрытие кода в веб-интерфейсе:
scripts/config -e CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT

# применяем конфиг
make olddefconfig

# собираем сжатый образ ядра
make -j"$(nproc)" bzImage

⚠️ - не забыть подставить конфиг из Техцентра!
В результате сборки должен будет появиться сжатый образ ядра Linux, доступный по пути - linux-next/arch/x86_64/boot/bzImage

2️⃣ Подготовка фаззера Syzkaller
Фаззер тоже берем самый новый) Клонируем репозиторий, собираем бинари, готовим свежайший образ 👩‍💻 Debian 13 для запуска в Qemu, скачиваем корпус для фаззера, пишем конфиг:

git clone https://github.com/google/syzkaller.git
cd syzkaller
make -j"$(nproc)" all
./create-image.sh --distribution trixie
mkdir workdir && cd workdir
wget https://portal.linuxtesting.ru/pub/syzkaller/corpus-2025-01-24.db.gpg --no-check-certificate
gpg --output corpus.db --decrypt corpus-2025-01-24.db.gpg

⚠️ - пароль от зашифрованного архива с корпусом для фаззинга от Техцентра дается по запросу. Но можно фаззить и без него, в этом случае syzkaller будет создавать этот корпус с нуля.
Далее создаем конфиг файл manager.cfg в корне syzkaller, указываем абсолютные пути:

{
  "target": "linux/amd64",
  "http": "localhost:22200",
  "workdir": "syzkaller/workdir",
  "kernel_obj": "linux-next",
  "image": "syzkaller/trixie.img",
  "sshkey": "syzkaller/trixie.id_rsa",
  "syzkaller": "syzkaller",
  "procs": 2,
  "type": "qemu",
  "sandbox": "none",
  "reproduce": true,
  "vm": {
    "count": 4,
    "cpu": 2,
    "mem": 4096,
    "kernel": "linux-next/arch/x86_64/boot/bzImage",
    "cmdline": "panic_on_warn=1 oops=panic slub_debug=FZP console=ttyS0 earlyprintk=serial mitigations=off vsyscall=native rcupdate.rcu_expedited=1"
  },
  "disable_syscalls": ["keyctl", "add_key", "request_key"]
}

То есть в процессе фаззинга будет запускаться 4 виртуальных машины, с 2 CPU/4Гб RAM, стартовать Debian 13 с ядром Linux 6.16 (KASAN). Внутри syzkaller будет гонять 2 процесса фаззинга, в которых будут постоянные запуски системных вызовов, в надежде уронить ядро.

🔗2-я часть
🔗3-я часть

#fuzz #syzkaller #linux