Universal Forwarder
Уязвимости
61
Эксплуатируемые
0
Макс. CVSS
9.8
Макс. EPSS
0.60122
Распределение по критичности
Критический
2
Высокий
20
Средний
29
Низкий
10
Затронутые диапазоны версий
8.1.0–8.1.118.2.0–8.2.128.2–8.2.129.1.0–9.1.9< 9.0
Также сопоставлено как (исходные строки): universal_forwarder,splunk
Топ уязвимостей
CVE-2022-32207Когда curl < 7.84.0 сохраняет cookie-файлы, alt-svc и данные hsts в локальные файлы, он делает операцию атомарной, завершая операцию переименованием из временного имени в конечное целевое имя файла. В этой операции переименования он может случайно *расширить* разрешения для целевого файла, оставив обновленный файл доступным для большего числа пользователей, чем предполагалось.
CVE-2021-22945При отправке данных на MQTT-сервер libcurl <= 7.73.0 и 7.78.0 при определенных обстоятельствах могла ошибочно сохранить указатель на уже освобожденную область памяти и повторно использовать ее в последующем вызове для отправки данных, а также повторно освободить ее.
CVE-2021-30560Использование памяти после освобождения в Blink XSLT в Google Chrome до версии 91.0.4472.164 позволяло удаленному злоумышленнику потенциально использовать повреждение кучи через специально созданную HTML-страницу.
CVE-2021-3520В lz4 была обнаружена уязвимость. Злоумышленник, который отправляет специально созданный файл приложению, связанному с lz4, может вызвать переполнение целого числа, что приведет к вызову memmove() с аргументом отрицательного размера, что вызовет запись за пределами границ и/или сбой. Наибольшее влияние этой уязвимости - на доступность, с некоторым потенциальным влиянием на конфиденциальность и целостность.
CVE-2022-32156В Splunk Enterprise и Universal Forwarder версий до 9.0 интерфейс командной строки Splunk (CLI) по умолчанию не проверял TLS-сертификаты при подключении к удаленному экземпляру платформы Splunk. После обновления до версии 9.0 см. Настройка проверки имени хоста TLS для Splunk CLI https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#Configure_TLS_host_name_validation_for_the_Splunk_CLI, чтобы включить исправление. Уязвимость не влияет на Splunk Cloud Platform. На момент публикации у нас нет доказательств эксплуатации этой уязвимости внешними сторонами.
Проблема требует условий, находящихся вне контроля потенциального злоумышленника, таких как атака «человек посередине». Следовательно, Splunk оценивает сложность атаки как высокую.
CVE-2022-27778Использование некорректно разрешенного имени, уязвимость, исправленная в 7.83.1, может привести к удалению неправильного файла, если `--no-clobber` используется вместе с `--remove-on-error`.
CVE-2022-22576В curl с 7.33.0 по 7.82.0 существует уязвимость неправильной аутентификации, которая может позволить повторно использовать соединения, аутентифицированные OAUTH2, без надлежащей проверки того, что соединение было аутентифицировано с теми же учетными данными, которые были установлены для этой передачи. Это относится к протоколам с поддержкой SASL: SMPTP(S), IMAP(S), POP3(S) и LDAP(S) (только openldap).
CVE-2021-22901curl 7.75.0 through 7.76.1 suffers from a use-after-free vulnerability resulting in already freed memory being used when a TLS 1.3 session ticket arrives over a connection. A malicious server can use this in rare unfortunate circumstances to potentially reach remote code execution in the client. When libcurl at run-time sets up support for TLS 1.3 session tickets on a connection using OpenSSL, it stores pointers to the transfer in-memory object for later retrieval when a session ticket arrives. If the connection is used by multiple transfers (like with a reused HTTP/1.1 connection or multiplexed HTTP/2 connection) that first transfer object might be freed before the new session is established on that connection and then the function will access a memory buffer that might be freed. When using that memory, libcurl might even call a function pointer in the object, making it possible for a remote code execution if the server could somehow manage to get crafted memory content into the correct place in memory.
CVE-2025-20298Уязвимость неправильного назначения разрешений в Universal Forwarder for Windows версий ниже 9.4.2, 9.3.4, 9.2.6 и 9.1.9 приводит к тому, что при новой установке или обновлении до уязвимой версии каталог установки Universal Forwarder for Windows (по умолчанию C:\Program Files\SplunkUniversalForwarder) получает неправильные разрешения [1]. Это позволяет пользователям, не являющимся администраторами, получить доступ к каталогу и всем его содержимому. Чтобы устранить эту уязвимость, необходимо обновить Universal Forwarder for Windows до версий 9.4.2, 9.3.4, 9.2.6, 9.1.9 или выше [1].
Источники:
- [1] https://advisory.splunk.com/advisories/SVD-2025-0602
CVE-2022-43551Уязвимость существует в curl <7.87.0 при проверке HSTS, которую можно обойти, чтобы заставить его продолжать использовать HTTP. Используя поддержку HSTS, curl можно настроить на использование HTTPS вместо использования небезопасного открытого HTTP-шага, даже если указывается HTTP в URL. Однако механизм HSTS может быть обойден, если имя хоста в заданном URL сначала использует символы IDN, которые заменяются на соответствующие ASCII символы в рамках преобразования IDN. Например, вместо общего ASCII точки (U+002E) `.` использовать символ UTF-8 U+3002 (ИДЕОГРАФИЧЕСКАЯ ЗАВЕРШАЮЩАЯ ТОЧКА). Затем в следующем запросе он не обнаруживает состояние HSTS и выполняет передачу открытым текстом. Поскольку он бы сохранял информацию в закодированном IDN, но искал бы её в декодированном IDN.
CVE-2022-42916В curl до версии 7.86.0 можно было обойти проверку HSTS, чтобы обманом заставить его оставаться с HTTP. Используя поддержку HSTS, curl можно инструктировать использовать HTTPS напрямую (вместо использования небезопасного шага HTTP в виде открытого текста), даже если HTTP указан в URL-адресе. Этот механизм можно было обойти, если имя хоста в данном URL-адресе использует символы IDN, которые заменяются аналогами ASCII в рамках преобразования IDN, например, с использованием символа UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) вместо общей ASCII полной остановки U+002E (.). Самая ранняя затронутая версия — 7.77.0 2021-05-26.
CVE-2022-42915curl до версии 7.86.0 имеет двойное освобождение памяти. Если curl сообщает использовать HTTP-прокси для передачи с URL-адресом, отличным от HTTP(S), он настраивает соединение с удаленным сервером, отправляя запрос CONNECT прокси, а затем туннелирует остальную часть протокола через него. HTTP-прокси может отклонить этот запрос (HTTP-прокси часто разрешают исходящие соединения только с определенными номерами портов, например, 443 для HTTPS) и вместо этого вернуть клиенту код состояния, отличный от 200. Из-за недостатков в обработке ошибок/очистки это может вызвать двойное освобождение памяти в curl, если в URL-адресе для передачи использовалась одна из следующих схем: dict, gopher, gophers, ldap, ldaps, rtmp, rtmps или telnet. Самая ранняя затронутая версия — 7.77.0.
CVE-2022-27782libcurl повторно использовал бы ранее созданное соединение, даже если была изменена опция, связанная с TLS или SSH, которая должна была запретить повторное использование. libcurl хранит ранее использованные соединения в пуле соединений для последующих передач, чтобы повторно использовать, если одно из них соответствует настройке. Однако некоторые параметры TLS и SSH были исключены из проверок соответствия конфигурации, что облегчило их соответствие.
CVE-2022-27781libcurl предоставляет опцию `CURLOPT_CERTINFO`, позволяющую приложениям запрашивать подробную информацию о цепочке сертификатов сервера. Из-за ошибочной функции вредоносный сервер может заставить libcurl, собранный с NSS, застрять в бесконечном цикле busy-loop при попытке получить эту информацию.
CVE-2022-27780Парсер URL curl неправильно принимает URL-разделители в процентах, такие как '/', при декодировании имени хоста в URL, делая его *другим* URL с использованием неправильного имени хоста при его последующем извлечении. Например, URL-адрес типа `http://example.com%2F127.0.0.1/` будет разрешен парсером и преобразован в `http://example.com/127.0.0.1/`. Этот недостаток можно использовать для обхода фильтров, проверок и многого другого.
CVE-2022-27775В curl 7.65.0 - 7.82.0 существует уязвимость раскрытия информации, которая при использовании IPv6-адреса, находящегося в пуле соединений, но с другим идентификатором зоны, может повторно использовать соединение.
CVE-2021-22946Пользователь может указать curl >= 7.20.0 и <= 7.78.0 требовать успешного обновления до TLS при разговоре с сервером IMAP, POP3 или FTP (`--ssl-reqd` в командной строке или `CURLOPT_USE_SSL` установлено в `CURLUSESSL_CONTROL` или `CURLUSESSL_ALL` с libcurl). Это требование можно было обойти, если бы сервер вернул правильно составленный, но совершенно законный ответ. Этот недостаток приводил к тому, что curl молча продолжал свои операции **без TLS** вопреки инструкциям и ожиданиям, раскрывая, возможно, конфиденциальные данные в открытом виде по сети.
CVE-2021-22926Приложения, использующие libcurl, могут запросить использование определенного клиентского сертификата в передаче. Это делается с помощью параметра `CURLOPT_SSLCERT` (`--cert` с инструментом командной строки). Когда libcurl построена для использования собственной библиотеки TLS macOS Secure Transport, приложение может запросить клиентский сертификат по имени или с именем файла - используя тот же параметр. Если имя существует как файл, он будет использоваться вместо имени. Если приложение запускается с текущим рабочим каталогом, доступным для записи другим пользователям (например, `/tmp`), злонамеренный пользователь может создать имя файла с тем же именем, которое приложение хочет использовать по имени, и, таким образом, обманом заставить приложение использовать сертификат на основе файла вместо сертификата, на который ссылаются по имени, заставляя libcurl отправлять неправильный клиентский сертификат в рукопожатии TLS-соединения.
CVE-2019-20838В libpcre в PCRE до версии 8.43 допускается переполнение буфера субъекта в JIT, когда UTF отключен, а \X или \R имеют более одного фиксированного квантификатора, что является проблемой, связанной с CVE-2019-20454.
CVE-2019-20454В PCRE до версии 10.34 обнаружено чтение за пределами выделенной области памяти, когда шаблон \X компилируется JIT и используется для сопоставления специально созданных объектов в режиме non-UTF. Приложения, использующие PCRE для анализа ненадежных входных данных, могут быть уязвимы к этому недостатку, который позволит злоумышленнику вызвать сбой приложения. Ошибка возникает в do_extuni_no_utf в pcre2_jit_compile.c.
CVE-2020-8286curl версии от 7.41.0 до 7.73.0 включительно уязвим для неправильной проверки отзыва сертификата из-за недостаточной проверки ответа OCSP.
CVE-2021-31566Неправильное разрешение ссылок может произойти при извлечении архива, что приведет к изменению режимов, времени, списков контроля доступа и флагов файла за пределами архива. Злоумышленник может предоставить вредоносный архив пользователю-жертве, который вызовет этот недостаток при попытке извлечь архив. Локальный злоумышленник может использовать этот недостаток для получения дополнительных привилегий в системе.
CVE-2023-23916Существует уязвимость, связанная с выделением ресурсов без ограничений или регулирования в curl <v7.88.0 на основе алгоритмов HTTP-сжатия "по цепочке", что означает, что ответ сервера может быть сжат несколько раз и потенциально с разными алгоритмами. Количество приемлемых "звеньев" в этой "цепочке декомпрессии" было ограничено, но ограничение было реализовано на основе каждого заголовка, что позволяло злонамеренному серверу вставлять практически неограниченное количество шагов сжатия, просто используя множество заголовков. Использование такой цепочки декомпрессии может привести к "бомбе malloc", в результате чего curl потратит огромное количество выделенной памяти кучи или попытается это сделать и вернет ошибки нехватки памяти.
CVE-2023-23914Уязвимость, связанная с передачей конфиденциальной информации в виде открытого текста, существует в curl <v7.88.0, что может привести к сбою функциональности HSTS, когда несколько URL-адресов запрашиваются последовательно. Используя поддержку HSTS, curl можно указать использовать HTTPS вместо использования небезопасного шага HTTP в виде открытого текста, даже если HTTP указан в URL-адресе. Однако этот механизм HSTS будет неожиданно игнорироваться последующими передачами, выполняемыми в той же командной строке, поскольку состояние не будет должным образом перенесено.
CVE-2022-32206curl < 7.84.0 поддерживает "цепочные" алгоритмы HTTP-сжатия, что означает, что ответ сервера может быть сжат несколько раз и, возможно, с использованием различных алгоритмов. Количество приемлемых "звеньев" в этой "цепочке декомпрессии" было неограниченным, что позволяло злоумышленному серверу вставлять практически неограниченное количество этапов сжатия. Использование такой цепочки декомпрессии могло привести к "бомбе malloc", в результате чего curl тратил огромное количество выделенной памяти кучи или пытался и возвращал ошибки нехватки памяти.