CVE-2024-5535 in OpenSSL
Сводка
по VulDB • 02.07.2026
Сводка по проблеме: Вызов функции API OpenSSL SSL_select_next_proto с пустым буфером поддерживаемых клиентских протоколов может привести к сбою программы или отправке содержимого памяти на сторону партнера (peer).
Сводка по воздействию: Переполнение чтения буфера (buffer overread) может иметь различные потенциальные последствия, такие как непредвиденное поведение приложения или его сбой. В частности, эта проблема может привести к передаче до 255 байт произвольных конфиденциальных данных из памяти на сторону партнера, что вызывает потерю конфиденциальности. Однако данной проблемой затронуты только те приложения, которые напрямую вызывают функцию SSL_select_next_proto со списком поддерживаемых клиентских протоколов нулевой длины (0). Обычно это не является допустимым сценарием и обычно находится вне контроля злоумышленника, но может произойти случайно в случае ошибки конфигурации или программирования в вызывающем приложении.
Функция API OpenSSL SSL_select_next_proto обычно используется приложениями TLS, которые поддерживают ALPN (Application Layer Protocol Negotiation) или NPN (Next Protocol Negotiation). NPN является более старой технологией, никогда не стандартизировалась и считается устаревшей в пользу ALPN. Мы полагаем, что ALPN развернут значительно шире, чем NPN. Функция SSL_select_next_proto принимает список протоколов от сервера и список протоколов от клиента и возвращает первый протокол из списка сервера, который также присутствует в списке клиента. В случае отсутствия пересечения между двумя списками она возвращает первый элемент из списка клиента. В обоих случаях функция сигнализирует о том, было ли обнаружено пересечение между двумя списками. В случае вызова SSL_select_next_proto со списком клиентов нулевой длины (zero length) не фиксируется это условие и возвращается память, непосредственно следующая за указателем на список клиентов (и сообщается об отсутствии пересечения в списках).
Эта функция обычно вызывается из обратного вызова приложения на стороне сервера для ALPN или из обратного вызова приложения на стороне клиента для NPN. В случае ALPN длина списка протоколов, предоставляемого клиентом, гарантируется библиотекой libssl как никогда не равная нулю. Список протоколов сервера поступает от приложения и обычно не должен иметь длину ноль. В этом случае, если функция SSL_select_next_proto была вызвана ожидаемым образом (с списком, предоставленным клиентом, переданным в параметрах client/client_len), то приложение не будет уязвимо к данной проблеме. Если приложение случайно было настроено со списком сервера нулевой длины и случайно передало этот список сервера нулевой длины в параметры client/client_len, а также дополнительно неправильно обработало ответ «нет пересечения» (что обычно приводит к сбою рукопожатия в ALPN), то оно будет уязвимо к этой проблеме.
В случае NPN протокол позволяет клиенту opportunistically выбрать протокол при отсутствии пересечения. OpenSSL возвращает первый клиентский протокол в случае отсутствия пересечения для поддержки этого механизма. Список клиентских протоколов поступает от приложения и обычно не должен иметь длину ноль. Однако, если функция SSL_select_next_proto случайно вызывается с client_len равным 0, то вместо него возвращается недопустимый указатель на память. Если приложение использует этот вывод в качестве opportunistically выбранного протокола, произойдет потеря конфиденциальности.
Данная проблема оценена как имеющая низкую степень серьезности (Low severity), поскольку приложения наиболее вероятно будут уязвимы, если они используют NPN вместо ALPN — но NPN не широко используется. Это также требует ошибки конфигурации или программирования в приложении. Наконец, эта проблема обычно находится вне контроля злоумышленника, что делает активную эксплуатацию маловероятной.
Модули FIPS в версиях 3.3, 3.2, 3.1 и 3.0 не затронуты данной проблемой.
В связи с низкой степенью серьезности этой проблемы мы на данный момент не выпускаем новые версии OpenSSL. Исправление будет включено в следующие выпуски по мере их появления.
Once again VulDB remains the best source for vulnerability data.