Curl допускает обход аутентификации и смешение пользовательских сессий

В curl и библиотеке libcurl обнаружено девять уязвимостей, которые затрагивают версии с 7.44.0 по 8.21.0. Они позволяют атакующему нарушить конфиденциальность и целостность данных, а также обойти механизмы безопасности. Уязвимости устранены в выпуске 8.22.0, вышедшем 2 сентября 2026 года.

Детали уязвимостей

Одна из наиболее заметных проблем связана с процедурой аутентификации SASL при работе с серверами LDAP. Когда curl работает с каталогами LDAP через библиотеку OpenLDAP и соединение не защищено протоколом TLS, злоумышленник, находящийся между клиентом и сервером, может отправить преждевременный или сокращённый ответ. Тогда неполная последовательность рукопожатия ошибочно интерпретируется как успешная криптографическая проверка. Это позволяет обойти проверку подлинности сервера и установить соединение с подставным узлом. При использовании защищённого протокола LDAPS проблема не возникает, поскольку проверка сертификата сервера отсекает подделку.

Другая группа уязвимостей приводит к смешению сессий разных пользователей. Например, ошибка в обработке аутентификации Negotiate возникает, когда запрос выполняется с пустыми учётными данными. В такой ситуации libcurl считает, что используется так называемый фоновый пользователь, чьи данные хранятся во внешнем провайдере аутентификации. Если этот пользователь меняется, программа может ошибочно отправить запрос одного пользователя через соединение, уже аутентифицированное для другого. Это возможно при повторном использовании HTTP-соединений, которое включено по умолчанию. Подобный недостаток присутствует и при работе с системным хранилищем сертификатов на Windows и macOS: libcurl может использовать ранее созданное HTTPS-соединение, не учитывая, что настройка хранилища изменилась. В результате данные, предназначенные для одной стороны, могут быть переданы другой.

Отдельные уязвимости связаны с файлами cookie, то есть небольшими фрагментами данных, которые веб-сайты сохраняют на стороне клиента. Из-за ошибки разбора заголовка Set-Cookie, когда перед атрибутом Secure стоит символ табуляции вместо пробела, файл cookie сохраняется без пометки Secure. Такой cookie впоследствии может быть отправлен по незашифрованному протоколу HTTP на тот же хост. Ещё одна проблема проявляется при включённой поддержке списка публичных суффиксов, который определяет домены верхнего уровня, такие как com или co.uk. Если сервер отправляет cookie для домена, который сам является публичным суффиксом, curl сохраняет её с областью действия на весь суффикс. Например, cookie, установленная доменом co.uk, становится доступной всем поддоменам, включая принадлежащие атакующему. Это приводит к нежелательной передаче данных третьим лицам.

Несколько недостатков относятся к классу ошибок использования после освобождения, когда программа обращается к памяти, которая уже была освобождена. Одна из них возникает при обработке потоков HTTP/2 Server Push, технологии, позволяющей серверу отправлять ресурсы клиенту до явного запроса. Для срабатывания требуется, чтобы приложение включило функцию push и совместное использование соединений. Другая связана с модулями OpenSSL 3: после разрушения родительского объекта соединения остаётся ссылка на уже освобождённый контекст. Оба случая требуют специфических условий и затрагивают только приложения, применяющие соответствующие возможности libcurl. Потенциально такие ошибки позволяют вызвать отказ в обслуживании или выполнить произвольный код, однако разработчики присвоили им низкий уровень опасности из-за сложности эксплуатации.

Также исправлены два обхода проверки сертификатов. Первый связан с привязкой соединения к определённому публичному ключу сервера в OpenSSL и его производных. При отключённой стандартной проверке сертификата и включённой привязке, если сервер не предоставляет сертификат, проверка не выполняется. Второй обход существует в сборках с библиотекой wolfSSL: при использовании кэша сертификатов и одновременной замене доверенного хранилища через специальную функцию обратного вызова, кэш может восстановить прежний список доверия. В результате сертификат, отклонённый новой конфигурацией, может быть принят.

Уязвимости затрагивают не только командную утилиту curl, но и многочисленные приложения, использующие библиотеку libcurl. Поскольку curl встроен в большое количество операционных систем, веб-серверов, средств автоматизации и программ, обновление требуется практически всем пользователям. Однако не каждый из этих недостатков легко эксплуатируется в реальных условиях. Например, проблема с wolfSSL актуальна только для сборок с этой библиотекой и только при вызове определённой функции обратного вызова. А уязвимость cookie с табуляцией требует, чтобы на сервере был размещён специально сформированный заголовок. Некоторые недостатки проявляются только на Windows или macOS, другие - только при использовании OpenLDAP или OpenSSL третьей версии.

Разработчики рекомендуют обновить curl и libcurl до версии 8.22.0. Также можно применить индивидуальные патчи, ссылки на которые приведены в бюллетенях безопасности. В качестве временных мер предлагается избегать использования LDAP без TLS, отключить HTTP/2 Server Push или запретить повторное использование соединений в сценариях с пустыми учётными данными и нестандартными настройками хранилищ сертификатов. Для cookie рекомендуется не использовать незашифрованные HTTP-соединения.

Выпуск большого количества исправлений одновременно указывает на постоянное внимание проекта к вопросам безопасности. Даже для таких зрелых инструментов, как curl, характерно появление новых ошибок, особенно связанных с управлением памятью и состояниями соединений. Регулярное обновление и аккуратная настройка параметров остаются главными средствами защиты. При этом важно понимать, что низкая оценка серьёзности отдельных уязвимостей не означает их полную безвредность, а лишь отражает сложность их использования в реальных атаках.

Детали уязвимостей

Ссылки