dcap-qvl реализует логику проверки котировок для DCAP (Data Center Attestation Primitives). Уязвимость, присутствующая в версиях до 0.3.9, …
dcap-qvl реализует логику проверки котировок для DCAP (Data Center Attestation Primitives). Уязвимость, присутствующая в версиях до 0.3.9, включает критический пробел в процессе криптографической проверки в dcap-qvl. Библиотека приносит залог QE Identity (включая qe_identity, qe_identity_signature и qe_identity_isser_chain) из PCCS. Тем не менее, он пропускает проверку подписи QE Identity против своей цепочки сертификатов и не обеспечивает соблюдение политических ограничений в отчете QE. Злоумышленник может подделывать данные QE Identity, чтобы занести в белый список вредоносного или не Intel Quoting Enclave. Это позволяет злоумышленнику подделывать QE и подписывать ненадежные котировки, которые верификатор примет как действительные. Фактически, это обходит всю модель безопасности удаленной аттестации, так как проверяющая больше не может доверять организации, ответственной за подписание котировок. Все развертывания, использующие библиотеку dcap-qvl для проверки котировок SGX или TDX, затрагиваются. Уязвимость была исправлена в dcap-qvl версии 0.3.9. Исправление реализует отсутствующую криптографическую проверку для подписи QE Identity и обеспечивает соблюдение необходимых проверок для MRSIGNER, ISVPRODID и ISVSVN против отчета QE. Пользователи пакетов `@phala/dcap-qvl-node` и `@phala/dcap-qvl-web` должны перейти на чистую реализацию JavaScript, `@phala/dcap-qvl`. Не существует известных обходных пути для этой уязвимости. Пользователи должны перейти на исправленную версию, чтобы обеспечить надлежащую проверку залога QE Identity.
Продукт не проверяет или некорректно проверяет сертификат.
https://cwe.mitre.org/data/definitions/295.html →Открыть в коллекции CWE →Злоумышленник эксплуатирует слабость, возникающую вследствие применения хеш-алгоритма с низкой устойчивостью к коллизиям, для генерации запросов на подпись сертификата (CSR), содержащих блоки коллизий в разделах «подписываемых данных». Злоумышленник отправляет один CSR на подписание доверенному удостоверяющему центру, а затем использует подписанный блок для того, чтобы второй сертификат выглядел подписанным тем же удостоверяющим центром. Вследствие хеш-коллизии оба сертификата, будучи различными, дают одно и то же хеш-значение, и подписанный блок одинаково работает с обоими сертификатами. В итоге второй сертификат X.509 злоумышленника, который удостоверяющий центр никогда не видел, оказывается подписанным и верифицированным этим удостоверяющим центром.
https://capec.mitre.org/data/definitions/459.html →Открыть в коллекции CAPEC →Злоумышленник эксплуатирует криптографическую слабость в реализации алгоритма проверки подписи для генерации действительной подписи без знания ключа.
https://capec.mitre.org/data/definitions/475.html →Открыть в коллекции CAPEC →