Hacker News Digest

CVE-2024-50264: кратко о сложнейшей гонке в AF_VSOCK
Уязвимость введена в 2016 г. (ядро 4.8); это race между connect() AF_VSOCK и POSIX-сигналом, приводящий к UAF 80-байтового объекта virtio_vsock_sock. Триггер доступен обычному пользователю без user-ns. Ограничения: объект быстро освобождается, UAF-запись делает kworker, система легко падает. За это баг получил Pwnie 2025 «Best Privilege Escalation».

Управление сигналом без самоубийства процесса
Вместо SIGKILL, который убивает эксплойт, используется «бессмертный» сигнал 33:

sev.sigev_signo = 33;
timer_create(CLOCK_MONOTONIC, &sev, &race_timer);
timer_settime(...);  // точный момент прерывания connect()

Сигнал 33 зарезервирован NPTL, процесс его не видит и не завершается.

kernel-hack-drill: тренажёр для ядерных атак
Проект https://github.com/a13xp0p0v/kernel-hack-drill автоматизирует:

• сборку нужных версий ядра Ubuntu 24.04 (6.11 OEM/HWE) с разными конфигурациями KASLR/KCFI/SLAB_QUARANTINE;
• запуск в KVM с заданным RAM/CPU и ssh-форвардингом;
• однокнопочный запуск PoC и сбор crash-дампов.

Инструмент позволил быстро перебирать стратегии перераспределения kmalloc-96, искать объекты-спрей, тестировать разные техники обхода защит и отлаживать эксплойт без ручной пересборки ядра.

Новый путь эксплуатации
Автор отказался от сложной цепочки @v4bel и @qwerty и применил упрощённую схему:

1. Спрей sendmsg()-controlled объектами размером 96 байт, чтобы перехватить освобождённый virtio_vsock_sock.
2. UAF-запись переписывает поле sk_prot, указывая на поддельную структуру proto в userspace-буфере.
3. При последующем вызове close() ядро переходит по контролируемому указателю и исполняет ROP-цепочку, поднимая shell до root.

kernel-hack-drill сократил время от идеи до рабочего PoC с недель до нескольких часов.

• Участники в восторге от глубокого и единоличного описания use-after-free, но признают, что текст местами труден для чтения из-за «роботизированной» подачи.
• Многие чувствуют себя «бесполезными» на таком низком уровне и восхищаются талантом исследователей уязвимостей.
• Поднимается вопрос о мотивации: исследователи редко чинят баги, потому что это требует других навыков и ломает их инсентивы.
• Обсуждается, поможет ли Rust в ядре Linux: write-after-free технически блокируется, но unsafe-области всё ещё оставляют риски.

• Зачем замедлять программу?
  Искать race-conditions, «виртуально» оценить выгоду оптимизации (как в Coz) и проверять точность профилировщиков. Для этого меняют расписание потоков или вставляют задержки.

• Как замедляют сейчас?
  Грубо: Thread.sleep, остановка потоков, вставка лишнего байт-кода. Это снижает точность.

• Наша идея
  Вставлять задержки внутри basic block на уровне x86. Нужны инструкции, которые:
  – надёжно тратят циклы;
  – не искажают семантику;
  – не оптимизируются CPU за счёт out-of-order.

• Проблема
  Современные процессоры выполняют независимые mov параллельно, поэтому просто добавить «тяжёлые» команды недостаточно — нужно учитывать зависимости и микроархитектуру.

• Используются разные способы замедления: от NOP-циклов и RDTSC до AVX-нагрузок и «тормозных» устройств вроде C64 Snail или Turbo-кнопки.
• Замедление помогает выявлять N+1-запросы, неработающие кеши и другие узкие места, которые на быстрых машинах незаметны.
• Современные CPU оптимизируют NOP/MOV на стадии переименования, поэтому они плохо подходят для точного контроля времени.
• Causal-profiling (Coz) и специальные прокси (Toxiproxy, dummynet) позволяют «ускорять» выбранный код, оставляя остальное медленным, чтобы заранее оценить выгоду оптимизации.

Therac-25: катастрофа, о которой должен знать каждый разработчик

21 марта 1986 г. в онкоцентре Восточного Техаса оператор установила пациента под 25-мегаэлектронвольтный пучок Therac-25. После лазерной привязки она повернула поворотный столик в положение «электронный режим», ввела параметры и нажала «Ввод». Машина выдала ошибку «MALFUNCTION 54» и остановилась. Оператор, привыкшая к частым глюкам, нажала «П» (продолжить) — стандартный шаг в инструкции.

Через секунды пациент вскрикнул: «Вы меня сожжёте!» Он получил дозу в сотни раз выше нормы, эквивалентную взрыву гранаты в теле. Через 21 день он умер от радиационных ожогов.

За 18 месяцев случилось ещё пять подобных инцидентов: трое погибли, двое получили тяжелейшие травмы. Причина — баг в коде: гонка между потоками ввода и механическим поворотом столика. Если оператор успевала изменить параметры до окончания поворота, программа «забывала» установить ограничитель и выдавала 25 МэВ электронов вместо 200 кэВ рентгеновского излучения.

Компания-изготовитель AECL отрицала проблему, пока не столкнулась с неопровержимыми доказательствами. Расследование показало:

• отсутствие независимого контроля безопасности;
• игнорирование жалоб;
• инструкции, учившие игнорировать ошибки.

Therac-25 стал учебным примером: безопасность должна быть встроена, а не добавлена «потом».

• Качество ПО — это не талант отдельных разработчиков, а результат всей организационной и технологической цепочки: процессов, тестирования, менеджмента и даже продаж.
• Therac-25 стал катастрофой, потому что убрали аппаратные блокировки, доверив безопасность исключительно софту; «взрослое» доверие к коду оказалось смертельно опасным.
• Многие комментаторы опасаются повторения случая в эпоху «vibe-coding» и генеративных ИИ-агентов, которых уже подключают к реальному оборудованию.
• Университеты по-разному преподают этику: кто-то рассказывает Therac-25 на первой лекции, кто-то вообще не упоминает.
• Главный вывод: безопасность требует не только «хорошего кода», но и независимых механических/аппаратных пределов, культуры безопасности и прозрачной отчётности.