Реверс-инжиниринг Docker образа 🧐

Если вы утеряли исходный Dockerfile для образа, который используете, или хотите глубже понять, как происходит сборка образов под капотом, у меня есть для вас несколько полезных утилит. Эти инструменты помогут вам восстановить исходный Dockerfile и расширить ваши знания о процессе создания образов

Прозаично, что эти утилиты также поставляются в формате Docker образов. Собственно, перейдём к практической части. Выполните любую из команд, приведённых ниже, чтобы восстановить Dockerfile:

sudo docker run -v /var/run/docker.sock:/var/run/docker.sock --rm dduvnjak/dockerfile-from-image $IMAGE_ID
sudo docker run -v /var/run/docker.sock:/var/run/docker.sock --rm laniksj/dfimage $IMAGE_ID
sudo docker run -v /var/run/docker.sock:/var/run/docker.sock --rm mrhavens/dedockify $IMAGE_ID

Где $IMAGE_ID - это ID вашего образа, Dockerfile которого вы хотите восстановить

После выполнения команды вы получите листинг с примерным содержимым Dockerfile'а. Эти три утилиты (dockerfile-from-image, dfimage, dedockify) практически идентичны относительно функционала. Единственное отличие в том, что первая написана на Ruby, а вторые две на Python. Под капотом они анализируют слои, которые образовались в ходе сборки образа. Каждая инструкция в Dockerfile создаёт новый слой в конечном артефакте (не все инструкции создают новый слой)

Для пущей автоматизации можно сделать alias, например:

alias dedockify="sudo docker run -v /var/run/docker.sock:/var/run/docker.sock --rm mrhavens/dedockify"

И потом при надобности:

dedockify $IMAGE_NAME

Также обратите внимание на утилиту dive, с помощью которой вы можете полазить по содержимому слоёв внутри Docker образа. Запуск этого инструмента возможен как в формате контейнера, так и в формате статического бинарного файла. Утилита подойдёт для того, чтобы посмотреть ФС образа на каждом этапе сборки. Этот функционал отлично подходит для отладки неполадок

alias dive="sudo docker run -ti --rm  -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive"

Например

dive nginx:latest

Если вы захотите применить инструмент в конвейере, то используйте следующую конструкцию:

CI=true dive $IMAGE

Канал: @unauth_papaya
Автор: Вадим Белоус
Хэштеги: #bash #trick #shell #devops #docker #ci #dedockify #reverse

Конвертация контейнера в виртуальную машину 😮

Нередко на технических собеседованиях на позицию DevOps-инженера задают каверзный вопрос: «В чем отличие контейнера от виртуальной машины?». Большинство кандидатов теряются при ответе на этот вопрос, а некоторые интервьюеры и сами до конца не понимают, какой ответ они хотят услышать от собеседуемого. Чтобы наглядно понять различия и никогда не возвращаться к этому вопросу, я покажу, как превратить контейнер в виртуальную машину и запустить ее в облаке Timeweb Cloud.

Ссылка на статью

Disclaimer: Автор канала не несёт ответственность за неправомерные действия, совершенные на основе изложенного в канале контента

Канал: @unauth_papaya
Автор: Вадим Белоус
Хэштеги: #linux #docker #timeweb #announcement #security #cloud #cont2virt #trick

Скрипт для поиска эндпоинтов сайта в HTML коде 🤓

Зайдите в DevTools и выполните в консоли следующий JavaScript код

javanoscript:(function(){var noscripts=document.getElementsByTagName("noscript"),regex=/(?<=(\"|\'|\`))\/[a-zA-Z0-9_?&=\/\-\#\.]*(?=(\"|\'|\`))/g;const results=new Set;for(var i=0;i<noscripts.length;i++){var t=noscripts[i].src;""!=t&&fetch(t).then(function(t){return t.text()}).then(function(t){var e=t.matchAll(regex);for(let r of e)results.add(r[0])}).catch(function(t){console.log("An error occurred: ",t)})}var pageContent=document.documentElement.outerHTML,matches=pageContent.matchAll(regex);for(const match of matches)results.add(match[0]);function writeResults(){results.forEach(function(t){document.write(t+"<br>")})}setTimeout(writeResults,3e3);})();

Disclaimer: Автор канала не несёт ответственность за неправомерные действия, совершенные на основе изложенного в канале контента

Канал: @unauth_papaya
Автор: Вадим Белоус
Хэштеги: #web #pentest #trick #js

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
noscripts/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
noscripts/config -e CONFIG_USB \
               -e CONFIG_USB_GADGET \
               -e CONFIG_USB_LIBCOMPOSITE

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

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

# Чтобы отобразить покрытие кода в веб-интерфейсе:
noscripts/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

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

3️⃣ Запуск фаззинга
В предыдущей части собрали ядро Linux и подготовили Syzkaller, теперь остается запустить фаззинг командой:

cd syzkaller
bin/syz-manager -config manager.cfg

Через некоторое время Syzkaller загрузит в память корпус, создаст виртуальные машины и поднимет веб-сервер по адресу http://localhost:22200 для контроля состояния фаззинга.
Минут через 5 выдаст такой результат выполнения команды:

2025/08/17 21:25:52 serving rpc on tcp://42507
2025/08/17 21:25:52 serving http on http://localhost:22200
2025/08/17 21:26:36 machine check:
disabled the following syscalls:
...
BinFmtMisc              : enabled
Comparisons             : enabled
Coverage                : enabled
DelayKcovMmap           : enabled
DevlinkPCI              : PCI device 0000:00:10.0 is not available
ExtraCoverage           : enabled
Fault                   : enabled
KCSAN                   : write(/sys/kernel/debug/kcsan, on) failed
KcovResetIoctl          : kernel does not support ioctl(KCOV_RESET_TRACE)
LRWPANEmulation         : netlink: adding device lowpan0 type lowpan link wpan0
Leak                    : enabled
NetDevices              : enabled
NetInjection            : enabled
NicVF                   : PCI device 0000:00:11.0 is not available
SandboxAndroid          : setfilecon: setxattr failed.
SandboxNamespace        : enabled
SandboxNone             : enabled
SandboxSetuid           : enabled
Swap                    : enabled
USBEmulation            : enabled
VhciInjection           : enabled
WifiEmulation           : enabled
syscalls                : 2408/8048

Заходим на веб-морду, там можно собирать и оценивать покрытие кода, видеть найденные краши, всю статистику и метрики фаззинга.
Через 1-2 часа Syzkaller уже пишет в лог первые найденные краши:

2025/08/17 21:57:33 VM 2: crash: KASAN: slab-use-after-free Write in __xfrm_state_delete
2025/08/17 22:11:53 VM 2: crash: possible deadlock in input_inject_event
2025/08/17 22:12:56 VM 3: crash: INFO: task hung in __iterate_supers

Кликнув на краш, можно посмотреть полный backtrace падения с указанием конкретных строк функций 😳

4️⃣ Поиск репродюсера
После нахождения краша, если syzkaller считает его детерминированным и в принципе воспроизводимым, он ставит его в очередь на поиск репродюсера. Далее, если есть свободные 4 виртуальных машины, то он задействует их для поиска репродюсера. Он может найти репродюсер либо написанный на языке syzlang, либо на языке Си, а может не найти его вовсе, бывает по разному, этот процесс пока не идеален.

⚠️ - занятые под репродюсинг крашей виртуальные машины, могут почти полностью парализовать фаззинг, потому как syzkaller оперирует только выделенным ему количеством виртуальных машин в конфиге.

К сожалению, пока не могу добиться от syzkaller поведения, когда сразу после нахождения краша, он запускал бы процесс поиска подходящего репродюсера для этого краша, хотя в конфиге стоит "reproduce": true. Если кто-то уже решал такую проблему - прошу подсказать в комментариях).

Для ручного поиска репродюсера на данный момент пользуюсь утилитой syz-repro из состава syzkaller, запускаю поиск репродюсера, указывая конфиг фаззера и лог краша:

cd syzkaller
bin/syz-repro -config manager.cfg workdir/crashes/6bfbc3ea5a876102628620dec078f4992586f034/log0

При этом так же запускается пул из 4-х виртуальных машин и в них уже целенаправленно выполняются программы, которые могут приводить к этому крашу. В случае успеха, сохраняет Си-репродюcер и пишет в лог: C file saved to repro.c.

🔗1-я часть - сборка ядра Linux и подготовка Syzkller
🔗3-я часть - запуск и минимизация репродюсера, разбор краша


#fuzz #syzkaller #linux

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

Напомню, что на предыдущих шагах удалось запустить Syzkaller и он уже нашел несколько интересных крашей:

KASAN: slab-use-after-free Read in xfrm_alloc_spi
general protection fault in xfrm_alloc_spi
possible deadlock in input_inject_event
WARNING in __rate_control_send_low

Для 1-го краша из списка выше мне удалось через syz-repro получить репродюссер. Идем дальше!

5️⃣ Проверка репродюсера
У нас уже есть код репродюсера на СИ, который приводит к этом крашу. Давайте проверим работает ли он. Для этого запустим виртуальную машину QEMU с нашим ядром и окружением Trixie, сделаем это через скрипт для удобства:

#!/bin/bash

bzImage='linux-next/arch/x86/boot/bzImage'
qemuImage='syzkaller/trixie.img'

qemu-system-x86_64 \
  -m 2G \
  -smp 2 \
  -kernel $bzImage \
  -append 'console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0 nokaslr' \
  -drive file=$qemuImage,format=raw \
  -net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \
  -net nic,model=e1000 \
  -enable-kvm \
  -nographic \
  -pidfile vm.pid

Это запускает виртуальную машину с 2 vCPU/2 ГБ RAM с нашим ядром bzImage и диском с дистрибутивом Debian 13 - trixie с выводом логов загрузки ядра и отключенным KASLR.
🟡После загрузки ядра логинимся root без пароля.
🟣Проверить с какими санитайзерами собрано ядро можно грепнув символы ядра (должно выдать не нулевое значение):

grep kasan /proc/kallsyms | wc -l

🔵Загружаем в виртуальную машину исходный код репродюсера, просто скопировав код, либо через scp:

scp -P 10021 -i trixie.id_rsa workdir/crashes/6bfbc3ea5a876102628620dec078f4992586f034/repro.c root@127.0.0.1:/root

🟢Компилируем бинарник репродьюсера и запускаем:

gcc repro.c -o repro
./repro

В случае использования pthread нужно добавить опцию `-pthread`

После этого происходит kernel panic 💥 и виртуальная машина зависает в этом состоянии - это подтверждает работоспособность репродюсера.
⚠️ - важно проверить чтобы краш в точности совпадал с тем, что нашел syzkaller.

6️⃣ Минимизация репродюсера
СИ-код, генерируемый syz-repro, часто избыточен, содержит комментарии и многочисленные лишние действия. И я обычно, либо вручную, либо с помощью ИИ провожу минимизацию, часто уже в процессе минимизации и упрощения кода, становится понятна природа бага.
Процесс примерно такой:
- убираем лишние строки, либо переписываем что-то;
- проверяем в QEMU воспроизводится ли баг всё еще? Если нет, откатываем, значит задели то что влияет на воспроизводимость;
- повторяем действия выше 🔄
Пример боевого мини репро, одного из реальных падений стабильной ветки ядра:

#include <fcntl.h>
#include <linux/cdrom.h>
#include <sys/ioctl.h>
#include <sys/mman.h>
#include <string.h>

#define SIZE 14

void main()
{
    unsigned char buf[SIZE];
    memset(buf, 0x42, SIZE);
    static struct cdrom_generic_command cgc;
    static const unsigned char cdb[12] = { 0x6f, 0x79, 0xa6, 0x9f, 0xa8, 0xa3, 0x5f, 0x4b, 0x77, 0xef, 0xec, 0x7d };
    memcpy(cgc.cmd, cdb, sizeof(cdb));
    cgc.buffer         = buf;
    cgc.buflen         = SIZE;
    cgc.data_direction = CGC_DATA_WRITE;
    int fd = open("/dev/cdrom", O_RDONLY | O_NONBLOCK);
    ioctl(fd, CDROM_SEND_PACKET, &cgc);
}

7️⃣ Разбор краша
Приведу несколько полезных рекомендаций, которые помогают в этом процессе:
- символизировать бэктрейс падения - https://google.github.io/kernel-sanitizers/SYMBOLIZER.html
(cat backtrace.txt | python3 symbolizer.py --linux=$PWD/linux-6.16);
- printk для отладки ядра;
- собрать репро с -ggdb -O0;
- удаленная отладка gdb, для этого добавить -s -S в опции запуска QEMU;
- найти похожие краши в сети;
- использовать git blame и прочее;

🌟 Заключение:
В итоге получилась достаточно объемная серия постов по фаззингу ядра Linux. Осталось только осветить тему подготовки, оформления и отправки патча в upstream ядра, но это думаю будет отдельным постом в будущем, на примере фикса реального бага ядра, найденного через Syzkaller.

🔗1-я часть - сборка ядра Linux и подготовка Syzkller
🔗2-я часть - запуск Syzkaller, поиск краша и репродюсcера

#fuzz #syzkaller #linux