David Gstir

Um problema de validação inadequada de certificado existe no arquivo `crypto/swupdate cms verify openssl.c`. O sistema confia em certificados X.509 não confiáveis incorporados em CMS SignedData durante o processo de construção da cadeia. Isso permite que um invasor que possua uma chave de assinatura de um intermediário irmão sob a mesma raiz incorpore esse intermediário na assinatura e instale atualizações maliciosas.

Ocorre um overflow de inteiro na função ext4fs read symlink no Das U-Boot. Isso acontece quando um sistema de arquivos ext4 manipulado com um tamanho de inode de 0xffffffff é utilizado, causando um malloc de zero e consequente sobrescrita de memória. O problema surge ao adicionar um a uma variável LE32 na função zalloc.

Ocorre um overflow de inteiro na função `sqfs resolve symlink` no DAS U-Boot através de um sistema de arquivos squashfs forjado com um tamanho de inode de `0xffffffff`, resultando em uma alocação malloc de zero e uma consequente sobrescrita de memória. Este problema pode ser acionado via um sistema de arquivos squashfs manipulado.

Ocorre um problema de consumo de pilha na função sqfs size no DAS U-Boot por meio de um sistema de arquivos squashfs manipulado com aninhamento profundo de links simbólicos. Este problema afeta a função de resolução de links simbólicos do SquashFS, levando a um estouro de pilha.

Integer overflows in memory allocation occur for a crafted squashfs filesystem via `sbrk`, via `request2size`, or because `ptrdiff t` is mishandled on x86 64. This issue affects the memory allocation in DAS U-Boot.

O problema está relacionado a um erro off-by-one na função sqfs search dir, o que leva à corrupção de memória heap ao listar diretórios SquashFS. Este erro ocorre porque o separador de caminho não é considerado em um cálculo de tamanho.

Foi identificado um problema no kernel Linux no qual chaves confiáveis do DCP podem causar travamento durante a criptografia e descriptografia da chave de criptografia do blob através do driver crypto do DCP quando endereços de pilha vmalloc estão habilitados. Isso é causado pelo uso incorreto de `sg init one()` com buffers de pilha alocados via vmalloc, especificamente `plain key blob`.

Nome do software vulnerável e versões afetadas: versões do tgt anteriores à 1.0.93 Descrição: O problema está relacionado ao fato de o Linux Target Framework (tgt) tentar gerar números aleatórios usando `rand` sem `srand`, resultando em uma semente PRNG previsível. Isso faz com que a sequência de desafios seja sempre idêntica. Um invasor capaz de registrar o tráfego de rede pode se aproveitar disso reproduzindo respostas anteriores, o que pode levar a uma violação da autenticação CHAP. Recomendações: Para versões anteriores à 1.0.93, atualize para a versão 1.0.93 ou posterior para resolver o problema. Como solução temporária, considere restringir o acesso à estrutura tgt até que um patch seja aplicado. Evite usar a estrutura tgt para autenticação até que o problema seja resolvido.

O problema está relacionado ao tratamento de chaves confiáveis no kernel do Linux. Especificamente, ao importar uma chave confiável baseada em DCP e, em seguida, exportá-la novamente, a chave de criptografia de blob (BEK) é descriptografada no local, fazendo com que o campo de blob da chave confiável contenha a BEK em texto simples. Como resultado, cada leitura subsequente dessa chave envia a BEK em texto simples, em vez da BEK criptografada, para o espaço do usuário. Esse problema é raro e geralmente ocorre ao importar uma chave confiável baseada em DCP e, em seguida, exportá-la novamente, o que não é um caso de uso comum.

The issue is related to the use of `rand()` as a fallback when `CARES RANDOM FILE` is not set, which can allow an attacker to exploit the lack of entropy by not using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG). This can potentially impact the integrity of protected information. The issue is specifically observed when cross-compiling c-ares for aarch64 android using the autotools build system.

The issue arises when /dev/urandom or RtlGenRandom() are unavailable, and c-ares uses `rand()` to generate random numbers for DNS query ids. This approach is not a Cryptographically Secure PseudoRandom Number Generator (CSPRNG) and lacks seeding by `srand()`, resulting in predictable output. The input from the random number generator is then used in a non-compliant RC4 implementation, potentially weakening its strength. Modern OS-provided CSPRNGs, such as `arc4random()`, are not utilized.