Удаление русских разработчиков из ядра 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

Реверс-инжиниринг 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