Уязвимость «Недостаточная проверка подлинности данных» в Gleam позволяет злоумышленнику подменить поддельное содержимое шестнадцатеричного пакета во время разрешения зависимостей. Во время разрешения зависимостей Gleam извлекает метаданные пакета из шестнадцатеричного репозитория с проверенной подписью, который соответствует требованиям к зависимостям каждого выпуска и внешней контрольной суммой SHA-256. После разрешения версий gleam_cli::dependents::lookup_package выполняет второй запрос к неподписанному Hex API через gleam_core::hex::get_package_release и записывает имена external_checksum и зависимостей из этого ответа JSON в манифест.toml вместо значений из проверенных метаданных репозитория.
Подпись репозитория Hex не распространяется на ответ API. Злоумышленник посередине, который может перехватить TLS с сертификатом, которому доверяет процесс Gleam (например, прокси-сервер, проверяющий TLS, используя центр сертификации в хранилище доверенных сертификатов операционной системы или добавленный через GLEAM_CACERTS_PATH) и который может изменить как ответ на выпуск API, так и соответствующий tar-архив репозитория, может предоставить архив пакета с соответствующей поддельной контрольной суммой без ключа подписи репозитория Hex. Gleam сверяет поддельный архив с поддельной контрольной суммой, принимает его и извлекает в качестве источника зависимостей, что приводит к потере целостности загруженного содержимого пакета.
Затрагиваются только проекты, которые разрешают или обновляют зависимости Hex, что происходит, когда манифест отсутствует, зависимость добавляется или обновляется или изменяются требования к зависимостям. Сборки, которые повторно используют неизмененный, заведомо исправный файл манифеста.toml, продолжают сверять архивы с закрепленной контрольной суммой. Эта проблема затрагивает блеск: с 0.18.0 до 1.18.0.
Показать оригинальное описание (EN)
Insufficient Verification of Data Authenticity vulnerability in Gleam allows an adversary in the middle to substitute forged Hex package contents during dependency resolution. During dependency resolution Gleam fetches package metadata from the signature-verified Hex repository, which covers each release's dependency requirements and SHA-256 outer_checksum. After resolving versions, gleam_cli::dependencies::lookup_package makes a second request to the unsigned Hex API through gleam_core::hex::get_package_release and records the outer_checksum and dependency names from that JSON response into manifest.toml, instead of the values from the verified repository metadata. The Hex repository signature does not cover the API response. An adversary in the middle who can intercept TLS with a certificate trusted by the Gleam process (for example a TLS-inspecting proxy using a CA in the operating system trust store or added through GLEAM_CACERTS_PATH), and who can modify both the API release response and the corresponding repository tarball, can supply a package archive with a matching forged checksum without the Hex repository signing key. Gleam verifies the forged tarball against the forged checksum, accepts it, and extracts it as a dependency source, resulting in loss of integrity of the downloaded package contents. Only projects that resolve or update Hex dependencies are affected, which happens when the manifest is missing, a dependency is added or updated, or dependency requirements change. Builds that reuse an unchanged, known-good manifest.toml continue to verify tarballs against its pinned checksum. This issue affects gleam: from 0.18.0 before 1.18.0.
Характеристики атаки
Последствия
Строка CVSS v4.0