Версия 1.6.0 библиотеки wolfSSH закрывает пять уязвимостей. Две из них касаются аутентификации и защиты канала напрямую. Одна позволяет атакующему "человек посередине" выдать себя за сервер и не вызвать подозрений. Другая работает на Windows, где один пользователь получает чужую сессию с более широкими правами. Ещё три дают возможность нагрузить процессор, занять память и повредить служебные данные. Уязвимы выпуски вплоть до 1.5.0. Библиотеку встраивают в устройства и приложения, поэтому обновление важно не только для тех, кто держит SSH-серверы в открытых сетях.
Детали уязвимостей
Подмену ключа хоста описывает CVE-2026-16516, критическая по классификации вендора. Клиент wolfSSH получал от сервера ключ, подписанный по схеме ECDSA (алгоритм цифровой подписи на эллиптических кривых). Библиотека при этом не сверяла, что кривая в ключе совпадает с той, о которой договорились стороны. Значит, злоумышленник между клиентом и сервером подставляет ключ на другой кривой и проходит проверку своим закрытым ключом. Для подлога нужна ещё одна слабость: небрежная проверка открытого ключа в самом приложении. Чтобы воспользоваться этим, атакующему нужно встать в разрыв канала, например в подконтрольной сети или на промежуточном узле. Проблема живёт во всех выпусках до 1.5.0 включительно.
Высокую степень опасности вендор присвоил CVE-2026-83540. Речь о серверной части wolfSSHd под Windows. Она держит один контекст аутентификации и один маркер входа на все соединения сразу. Разные сессии пишут туда свои данные и читают чужие. Поэтому владелец обычной учётной записи может попасть в сессию администратора. Так ведут себя оба способа входа: и по паролю, и по открытому ключу. Сборки для других систем не задеты, и Linux-серверы этим путём не пострадают. Ошибку нашли сами разработчики wolfSSL при внутреннем тестировании, и она тянется с 1.4.15 по 1.5.0. Тем, кто принимает подключения к Windows-серверу из недоверенных сетей, стоит считать риск реальным, а не теоретическим.
Три оставшиеся уязвимости помечены как средние. Первая связана с обменом ключами по методу diffie-hellman-group-exchange-sha256. Сервер wolfSSH принимал от неаутентифицированного клиента сообщения, которые в норме отправляет только сервер. После этого он запускал обработчик клиентской стороны и проверял на простоту группу, выбранную атакующим. Размер такой группы достигает 8192 бит. Для 4096-битного простого числа счёт занимает примерно половину секунды на каждый килобайт пакета. Затем обмен ключами продолжался, но уже в клиентской роли. Один поток атакующего надолго занимает процессор. Затронуты версии с 1.2.0 по 1.5.0, причём дорогая проверка появилась с 1.5.0. Сборки с флагом WOLFSSH_NO_DH_GEX_SHA256 не уязвимы. О находке сообщила группа исследователей, перечисленная в благодарностях выпуска.
Вторая средняя уязвимость касается перенаправления портов. При сборке с ключом --enable-fwd сервер открывал каналы forwarded-tcpip, не обращаясь к функции политики перенаправления. Клиент тоже принимал такие каналы для туннелей, которые сам не заказывал. В итоге удалённая сторона заставляла узел выделять память под каналы, которых приложение не разрешало. Проблема затрагивает версии с 1.4.8 по 1.5.0. Третья средняя уязвимость прячется в функции wolfSSH_RealPath(), которая собирает путь из частей. Она ограничивала каждую часть остатком свободного места, а не размером буфера. Как только собранный путь переходил половину отметки, счётчик длины переполнялся, и копирование теряло границы. Специально составленный путь в SFTP (передача файлов поверх SSH) дописывал завершающий нулевой байт за границей стекового буфера. Это портит соседнее значение и роняет процесс. Нужна аутентифицированная сессия, а сборки для Windows здесь ни при чём. Приложения, которые вызывают wolfSSH_RealPath() с буфером меньше входных данных, рискуют сильнее. Затронуты версии с 1.4.11 по 1.5.0.
Лечение одно - обновление до 1.6.0. Если перенести его нельзя, остаются обходные меры. Сборку без поддержки diffie-hellman-group-exchange-sha256 получают, выставив WOLFSSH_NO_DH_GEX_SHA256. На Windows разумно ограничить доступ к wolfSSHd и не выставлять сервер в недоверенные сети. Для SFTP помогает осторожность с путями извне и проверка размера буфера при вызове wolfSSH_RealPath(). Приложениям с функцией обратного вызова для проверки открытого ключа полезно убедиться, что она отклоняет неподходящие кривые. Наконец, стоит поискать в журналах следы необычных согласований ключей и лишних сессий: часть проблем проявляется именно там.
wolfSSH входит в семейство wolfSSL, и его часто берут для встраиваемых систем, где места под крупные реализации SSH нет. Такие проекты обновляют редко, поэтому уязвимости живут в них годами. Пять исправлений в одном выпуске показывают, что проверка типов ключей, общие буферы и политики перенаправления остаются слабым местом даже в зрелых библиотеках. Атака "человек посередине" требует доступа к каналу, зато не оставляет следов в журналах приложений. Смешение маркеров входа на Windows опасно для тех, кто держит серверы в общем домене. В описании выпуска нет упоминаний об атаках, где эти уязвимости уже использовали, однако тянуть с переходом на 1.6.0 не стоит.
Ссылки
