teamos-hub/regresshionЭто POC, который я написал для CVE-2024-6387
Qualys Security Advisory
regreSSHion: RCE в сервере OpenSSH на системах Linux на базе glibc (CVE-2024-6387)
Краткое описание SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 (Debian 3.0r6, от 2005)
Всё, что нужно — это прыжок веры
-- The Interrupters, "Leap of Faith"
Предварительное замечание: OpenSSH — одно из самых защищённых программных обеспечений в мире; эта уязвимость — одна оплошность в иначе почти безупречной реализации. Его архитектура защиты в глубину и код являются образцом и источником вдохновения, и мы благодарим разработчиков OpenSSH за их образцовую работу.
Мы обнаружили уязвимость (состояние гонки в обработчике сигналов) в сервере OpenSSH (sshd): если клиент не проходит аутентификацию в течение LoginGraceTime секунд (по умолчанию 120, 600 в старых версиях OpenSSH), то обработчик SIGALRM sshd вызывается асинхронно, но этот обработчик сигнала вызывает различные функции, которые не являются async-signal-safe (например, syslog()). Это состояние гонки затрагивает sshd в его конфигурации по умолчанию.
В ходе расследования мы поняли, что эта уязвимость на самом деле является регрессией CVE-2006-5051 ("Состояние гонки в обработчике сигналов в OpenSSH до версии 4.4, позволяющее удалённым злоумышленникам вызвать отказ в обслуживании (аварийное завершение) и, возможно, выполнить произвольный код"), которая была сообщена в 2006 году Марком Даудом.
Эта регрессия была введена в октябре 2020 года (OpenSSH 8.5p1) коммитом 752250c ("revised log infrastructure for OpenSSH"), который случайно удалил "#ifdef DO_LOG_SAFE_IN_SIGHAND" из sigdie(), функции, которая напрямую вызывается обработчиком SIGALRM в sshd. Другими словами:
OpenSSH < 4.4p1 уязвим к этому состоянию гонки в обработчике сигналов, если не был пропатчен с обратной совместимостью против CVE-2006-5051 или не исправлен против CVE-2008-4109, который был некорректным исправлением для CVE-2006-5051;
4.4p1 <= OpenSSH < 8.5p1 не уязвим к этому состоянию гонки в обработчике сигналов (потому что "#ifdef DO_LOG_SAFE_IN_SIGHAND", добавленный в sigdie() патчем для CVE-2006-5051, превратил эту небезопасную функцию в безопасный вызов _exit(1));
8.5p1 <= OpenSSH < 9.8p1 снова уязвим к этому состоянию гонки в обработчике сигналов (потому что "#ifdef DO_LOG_SAFE_IN_SIGHAND" был случайно удалён из sigdie()).
Эта уязвимость эксплуатируется удалённо на системах Linux на базе glibc, где syslog() сам вызывает async-signal-unsafe функции (например, malloc() и free()): неаутентифицированное удалённое выполнение кода с правами root, поскольку затрагивает привилегированный код sshd, который не изолирован (sandboxed) и работает с полными правами. Мы не исследовали другие libc или операционные системы; но OpenBSD, заметим, не уязвим, потому что его обработчик SIGALRM вызывает syslog_r(), более безопасную для async-signal версию syslog(), которая была изобретена OpenBSD в 2001 году.
Чтобы удалённо эксплуатировать эту уязвимость (насколько нам известно, CVE-2006-5051 ранее никогда не был успешно эксплуатирован), мы черпали вдохновение из провидческой статьи "Delivering Signals for Fun and Profit", опубликованной в 2001 году Михалом Залевским:
https://lcamtuf.coredump.cx/signals.txt
Тем не менее, мы сразу столкнулись с тремя основными проблемами:
С теоретической точки зрения, мы должны найти полезный путь кода, который, если его прервать в нужный момент сигналом SIGALRM, оставляет sshd в нестабильном состоянии, и затем мы должны эксплуатировать это нестабильное состояние внутри обработчика SIGALRM.
С практической точки зрения, мы должны найти способ достичь этого полезного пути кода в sshd и максимизировать наши шансы прервать его в нужный момент.
С точки зрения времени, мы должны найти способ ещё больше увеличить наши шансы прервать этот полезный путь кода в нужный момент удалённо.
Чтобы сосредоточиться на этих трёх проблемах, не борясь сразу со всеми современными защитами операционной системы (в частности, ASLR и NX), мы решили сначала эксплуатировать старые версии OpenSSH на i386, а затем, основываясь на этом опыте, современные версии:
Сначала, "SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3", из "debian-30r6-dvd-i386-binary-1_NONUS.iso": это первая версия Debian, в которой разделение привилегий включено по умолчанию и которая пропатчена против всех критических уязвимостей той эпохи (в частности, CVE-2003-0693 и CVE-2002-0640).
Чтобы удалённо эксплуатировать эту версию, мы прерываем вызов free() сигналом SIGALRM (внутри кода разбора открытого ключа sshd), оставляем кучу в нестабильном состоянии и эксплуатируем это нестабильное состояние во время другого вызова free() внутри обработчика SIGALRM.
В наших экспериментах в среднем требуется ~10 000 попыток, чтобы выиграть это состояние гонки; т.е. при 10 соединениях (MaxStartups), принятых за 600 секунд (LoginGraceTime), в среднем требуется ~1 неделя, чтобы получить удалённую root-оболочку.
Во-вторых, "SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3", из "ubuntu-6.06.1-server-i386.iso": это последняя версия Ubuntu, которая ещё уязвима к CVE-2006-5051 ("Состояние гонки в обработчике сигналов в OpenSSH до версии 4.4").
Чтобы удалённо эксплуатировать эту версию, мы прерываем вызов pam_start() сигналом SIGALRM, оставляем одну из структур PAM в нестабильном состоянии и эксплуатируем это нестабильное состояние во время вызова pam_end() внутри обработчика SIGALRM.
В наших экспериментах в среднем требуется ~10 000 попыток, чтобы выиграть это состояние гонки; т.е. при 10 соединениях (MaxStartups), принятых за 120 секунд (LoginGraceTime), в среднем требуется ~1-2 дня, чтобы получить удалённую root-оболочку.
Наконец, "SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2", из "debian-12.5.0-i386-DVD-1.iso": это текущая стабильная версия Debian, и она уязвима к регрессии CVE-2006-5051.
Чтобы удалённо эксплуатировать эту версию, мы прерываем вызов malloc() сигналом SIGALRM (внутри кода разбора открытого ключа sshd), оставляем кучу в нестабильном состоянии и эксплуатируем это нестабильное состояние во время другого вызова malloc() внутри обработчика SIGALRM (точнее, внутри syslog()).
В наших экспериментах в среднем требуется ~10 000 попыток, чтобы выиграть это состояние гонки, так что ~3-4 часа при 100 соединениях (MaxStartups), принятых за 120 секунд (LoginGraceTime). В конечном счёте, в среднем требуется ~6-8 часов, чтобы получить удалённую root-оболочку, потому что мы можем правильно угадать адрес glibc только в половине случаев (из-за ASLR).
Это исследование ещё в процессе:
мы нацеливались только на виртуальные машины, не на bare-metal серверы, на в основном стабильной сетевой линии (~10ms джиттер пакетов);
мы убеждены, что различные аспекты наших эксплойтов могут быть значительно улучшены;
мы начали работу над эксплойтом для amd64, что гораздо сложнее из-за более сильного ASLR.
Через несколько дней после начала нашей работы над amd64 мы заметили следующий отчёт об ошибке (в публичном Bugzilla OpenSSH) о взаимоблокировке в обработчике SIGALRM sshd:
https://bugzilla.mindrot.org/show_bug.cgi?id=3690
Поэтому мы решили немедленно связаться с разработчиками OpenSSH (чтобы сообщить им, что эта взаимоблокировка вызвана эксплуатируемой уязвимостью), приостановили нашу работу над amd64 и начали писать это уведомление.