11 октября 2023 года была замечена и устранена уязвимость высокого уровня, которая касалась переполнения буфера, в популярном инструменте и библиотеке curl. Хоть и оказалось, что риска эксплуатации она не несет, недостаток восприняли очень серьезно из-за масштаба потенциальных последствий. Эта публикация содержит предысторию, техническую информацию об этой уязвимости, указания для ее устранения и рассуждения о будущих перспективах.
Общая информация о происшествии
- 11 октября 2023 года эту уязвимость обнаружили, и ее исправление включили в релиз 8.4.0.
- CVE-2023-38545 влияет на все версии curl, начиная с 7.69.0, но ей нужны очень специфические условия для эксплуатации. Атак пока не обнаружили.
- ПО, связанные с инструментом curl или содержащие библиотеку libcurl, рекомендуется исправить или обновить как минимум до версии 8.4.0. Отказ от использования прокси SOCKS5 с curl также устраняет проблему.
- Миллиарды уязвимых версий curl по всему миру, вероятно, будут оставаться в сети годами, создавая долгосрочный риск, если их когда-нибудь смогут эксплуатировать.
Когда Даниэль Стенберг, мейнтейнер инструмента и библиотеки curl, объявил, что обнаружена серьезная уязвимость, и отказался сообщать о дополнительных подробностях, пока не будет готова исправление, мир кибербезопасности затаил дыхание. В той или иной форме open-source curl используется в миллиардах инсталляций ПО, и недостаток, который можно удаленно эксплуатировать, мог бы затмить кризис Log4j с точки зрения последствий.
К счастью, этого не произошло. Оказалось, что недостаток был уязвимостью переполнения буфера, которая влияла только на ограниченную часть функционала curl и только в очень конкретных обстоятельствах. В настоящее время никаких практических способов ее эксплуатации не было найдено или замечено. Эта уязвимость была устранена в curl 8.4.0, и все установки curl должны быть исправлены или обновлены по крайней мере до этой версии.
Можно подумать, к чему такая суматоха? Хоть мы и не будем иметь дело с другим Log4Shell (или с неизбежным псевдонимом Curl4Shell), но последствия могут проявить себя спустя много лет. Уязвимость также сочетает в себе несколько распространенных проблем с безопасностью и была подробно описана разработчиком, который заметил и устранил ее, поэтому она стоит более глубокого анализа.
Что такое curl, и где он используется?
Curl (иногда пишется как cURL) является основным инструментом командной строки и библиотекой для связи программы с URL-адресами и получения ответов. По сути, если используется скрипт или программа C/C++, которой нужны данные с веб-страницы или API, очень вероятно, что curl определенным образом вовлечен в процесс.
Большинство операционных систем внедряются вместе с этим инструментом, а связанная библиотека libcurl вызывается либо включена практически в любую программу C/C++, которая коммуницирует через HTTP. Это также касается встроенных систем в устройствах, подключенных к Интернету. Поэтому, по оценкам Даниэля Стенберга, может существовать около 20 миллиардов установок curl. По сравнению с этим, заголовки “Log4j есть повсюду” бесспорно кажутся преувеличенными.
Уязвимость переполнения буфера динамической памяти в curl
Даниэль Стенберг подробно описал историю и технические детали уязвимости в своем блоге, но вот краткая упрощенная версия:
- Curl имеет много режимов работы, включая один для коммуникации через прокси SOCKS5, который можно применять для туннелирования трафика из внутренней сети (подобно VPN) и для обхода фильтров трафика. Уязвимость влияет только на curl, если используется в режиме SOCKS5.
- Во время редактирования старого кода для улучшения качества соединений SOCKS5 была допущена ошибка при обработке слишком длинных имен хостов (более 255 байтов). Вместо того чтобы отклонить их, что было бы ожидаемо (DNS дает ограничение в 255 байт, поэтому все, что весит больше, вероятно, не разрешается), curl переключается с удаленного режима на локальный и снова пытается преобразовать имя хоста.
- Если соединение SOCKS5 недостаточно быстрое, curl ожидает дополнительные данные и продолжает работу. Из-за бага он не фиксирует, что должен работать в локальном режиме, и снова пытается отдаленно преобразовать слишком длинное имя хоста, но на этот раз он его все же передает.
- Код преобразовывает и отправляет имя хоста, не проверяя, сколько оно занимает места. Если размер буфера составляет от 16 КБ до 64 КБ, и указано очень длинное имя хоста, может произойти переполнение буфера, которое перепишет смежную память. Командная строка curl по умолчанию настроена на 100 КБ и уязвима только при изменении этого размера, но программы, использующие библиотеку libcurl, имеют дефолтное значение 16 КБ, что делает их уязвимыми.
- Атака может пройти успешно, только если операционная система не защищает память от повреждения. Злоумышленник также сталкивается с дополнительными сложностями из-за ограниченного набора символов, разрешенного в имени хоста.
Эта публикация перечисляет даже не все условия, необходимые для проявления уязвимости. Опять же, вспоминая Log4Shell, где одна строка текста, отправленная на сервер в Интернете, смогла вызвать выполнение кода, создается впечатление, что недостаток curl невероятно сложно эксплуатировать. Однако все очень быстро меняется. Злонамеренные хакеры находят все новые и новые способы для осуществления атак, поэтому важно все исправить как можно раньше.
Раскрытие уязвимости, устранение рисков и привычная паника насчет безопасности
Несмотря на низкий риск и отсутствие продемонстрированного способа эксплуатации уязвимости, Даниэль Стенберг очень серьезно отнесся к отчету и не раскрывал никаких подробностей о баге (даже каких версий это коснулось), пока не появилось исправление. Перед публикацией его предоставили мейнтейнерам ОС, чтобы они могли обновить curl в своих системах. Эта дополнительная задержка продлила время спекуляций по поводу потенциально разрушительного влияния уязвимости.
Патч и полные сведения об уязвимости были опубликованы 11 октября 2023 года, и все вздохнули с облегчением: страхи не оправдались. Обновление устранило проблему и, начиная с версии 8.4.0, curl отклоняет слишком длинные имена хостов и отправляет сообщения об ошибке. Это устраняет уязвимость и делает безопасным использование curl в режиме SOCKS5.
Но это только начало, ведь, как и со всеми исправлениями популярного ПО, сложно обновить все. Не все пользователи curl могут сделать это сразу. И многие могут даже не знать, что их система или программа использует curl. Инструмент и библиотека устанавливаются вместе с большинством операционных систем или уже включены в них. Это также касается встроенных систем (например, устройства IоТ и сетевые устройства) и ПО, которые работают в виртуальных машинах и контейнерах.
Рекомендации по устранению рисков (из официальных советов):
- Обновить curl до версии 8.4.0.
- Применить патч в локальной версии.
- Не использовать прокси CURLPROXY_SOCKS5_HOSTNAME из curl.
- Не устанавливать socks5h:// переменную среды прокси.
Еще одно звено в хрупкой цепочке поставки ПО
Как и в случае с каждой резонансной уязвимостью управления памятью, первоначальной реакцией были призывы избавиться от всего софта C/C++ и переписать его модным безопасным для памяти языком, чтобы наконец не видеть переполнение буфера на первых местах в топ 25 CWE. Это было бы прекрасно в теории, но совершенно невыполнимо на практике. Особенно для такого инструмента как curl, который широко используют в течение более двух десятилетий.
Весь этот страх можно списать на излишнюю осторожность со стороны мейнтейнера. Многие другие разработчики ПО, как для проектов с открытым исходным кодом, так и для коммерческих, вероятно, отнеслись бы к этой проблеме как к обычному низкоприоритетному исправлению бага и добавили бы это куда-нибудь в примечания к релизу для следующей запланированной версии. Но для Даниэля Стенберга безопасность сверхважна. Он чувствует бремя ответственности как один из тех, кто поддерживает основы всей современной цифровой инфраструктуры.
Даже после релиза патча миллионы уязвимых инсталляций curl, вероятно, будут существовать многие годы. Если эффективная атака когда-либо будет обнаружена и использована, это может иметь ужасающие последствия. Учитывая хрупкость глобальной цепочки поставки ПО, следует всегда помнить о важности кибербезопасности.
