5.2 Beta 2. TLS-валидация системного https_dns_proxy

[rand]

KeeneticOS 5.2 Beta 2 (KN-1011) — вопрос о TLS-валидации системного https_dns_proxy

При тестировании системного /usr/sbin/https_dns_proxy обнаружил проблему с проверкой доверия к TLS-сертификатам при непосредственном запуске бинарника.

Впервые поведение воспроизведено на 5.2 Beta 1, затем независимо подтверждено на 5.2 Beta 2 (5.02.B.2.0-2), несмотря на изменение самого исполняемого файла.

Проверка проводилась на локальном тестовом TLS-сервере, без вмешательства в работу штатных DNS-сервисов и без обращения к сторонним ресурсам.

Установлено, что поведение проверки цепочки доверия сертификата зависит от параметров запуска. При этом использование штатного DNS-over-HTTPS через DNS-менеджер KeeneticOS отдельно не проверялось, поэтому утверждать о наличии уязвимости в стандартной пользовательской конфигурации оснований пока нет.

Подробные шаги воспроизведения и журналы готов передать команде безопасности через официальный конфиденциальный канал.

Хотелось бы уточнить, является ли непосредственный запуск этого системного компонента поддерживаемым сценарием и как обеспечивается проверка доверия сертификатов при штатном использовании DoH.

[Denis P]

1 час назад, rand сказал:

KeeneticOS 5.2 Beta 2 (KN-1011) — вопрос о TLS-валидации системного https_dns_proxy

При тестировании системного /usr/sbin/https_dns_proxy обнаружил проблему с проверкой доверия к TLS-сертификатам при непосредственном запуске бинарника.

Впервые поведение воспроизведено на 5.2 Beta 1, затем независимо подтверждено на 5.2 Beta 2 (5.02.B.2.0-2), несмотря на изменение самого исполняемого файла.

Проверка проводилась на локальном тестовом TLS-сервере, без вмешательства в работу штатных DNS-сервисов и без обращения к сторонним ресурсам.

Установлено, что поведение проверки цепочки доверия сертификата зависит от параметров запуска. При этом использование штатного DNS-over-HTTPS через DNS-менеджер KeeneticOS отдельно не проверялось, поэтому утверждать о наличии уязвимости в стандартной пользовательской конфигурации оснований пока нет.

Подробные шаги воспроизведения и журналы готов передать команде безопасности через официальный конфиденциальный канал.

Хотелось бы уточнить, является ли непосредственный запуск этого системного компонента поддерживаемым сценарием и как обеспечивается проверка доверия сертификатов при штатном использовании DoH.

если вы выполняли тестирование непосредственно из entware то и пути к библиотекам и сертификатам там будут не системные
например

Спойлер

~ # ldd /usr/sbin/https_dns_proxy
        linux-vdso.so.1 (0x0000007f9af3b000)
        libcurl.so.4 => /opt/lib/libcurl.so.4 (0x0000007f9ae45000)
        libndm.so => not found
        libssp.so.0 => /opt/lib/libssp.so.0 (0x0000007f9ae32000)
        libgcc_s.so.1 => /opt/lib/libgcc_s.so.1 (0x0000007f9ae0f000)
        libc.so => not found
        libnghttp2.so.14 => /opt/lib/libnghttp2.so.14 (0x0000007f9add1000)
        libssl.so.3 => /opt/lib/libssl.so.3 (0x0000007f9aca8000)
        libcrypto.so.3 => /opt/lib/libcrypto.so.3 (0x0000007f9a751000)
        libz.so.1 => /opt/lib/libz.so.1 (0x0000007f9a72b000)
        libc.so.6 => /opt/lib/libc.so.6 (0x0000007f9a5bc000)
        libdl.so.2 => /opt/lib/libdl.so.2 (0x0000007f9a5a8000)
        libpthread.so.0 => /opt/lib/libpthread.so.0 (0x0000007f9a57a000)
        /lib/ld-musl-aarch64.so.1 => /opt/lib/ld-linux-aarch64.so.1 (0x0000007f9af0d000)

 

Изменено вчера в 10:18 пользователем Denis P

[rand]

5 часов назад, Denis P сказал:

если вы выполняли тестирование непосредственно из entware то и пути к библиотекам и сертификатам там будут не системные

Спасибо за замечание. Проверил эту гипотезу отдельно.

Повторил оба TLS-теста на KeeneticOS 5.2 Beta 2 (5.02.B.2.0-2), запуская системный /usr/sbin/https_dns_proxy через env -i с очищенным окружением.

Дополнительно проверил реальные загруженные библиотеки через /proc/PID/maps непосредственно у обоих тестовых процессов.

В обоих случаях используются исключительно системные библиотеки KeeneticOS:

/usr/lib/libcrypto.so.3
/usr/lib/libcurl.so.4.8.0
/usr/lib/libndm.so
/usr/lib/libssl.so.3

Без -P, PID 31289:

* TLS-соединение с самоподписанным сертификатом (корректный SAN) устанавливается.
* Прокси отправляет POST /dns-query HTTP/1.1.
* Затем возникает ожидаемый тайм-аут curl 28, поскольку тестовый HTTPS-сервер не реализует DoH.

С -P, PID 31326:

* Тот же сертификат отклоняется: self-signed certificate (18).
* curl возвращает ошибку 60.
* HTTP POST не отправляется.

Также проверил рабочие экземпляры прокси: они загружают системные библиотеки из /usr/lib, а их запуск предусматривает очистку LD_LIBRARY_PATH и LD_BIND_NOW.

Короче говоря, подмена библиотек через Entware в данном случае исключена, а обнаруженное поведение системного бинарника воспроизводится в чистом окружении.

Уточню, что речь исключительно о моём самостоятельном запуске /usr/sbin/https_dns_proxy. Поведение штатного DNS-менеджера KeeneticOS я не исследовал.