1Seal

**Nome do Software Vulnerável e Versões Afetadas** nimiq-blockchain versões anteriores a 1.4.0 **Descrição** No componente de descoberta network-libp2p, o sistema aceita atualizações de PeerContact assinadas de pares não confiáveis e as armazena em um livro de contatos de pares. Como não há validação para garantir que a lista de endereços não esteja vazia, um invasor pode inserir um contato de par assinado com uma lista de endereços vazia. Quando a função `known peers()` em `PeerContactBook` tenta construir um livro de endereços, ela chama `addresses.first().expect()`, o que provoca um pânico se a lista estiver vazia. Consequentemente, qualquer chamada ao endpoint 'get address book' via RPC ou cliente web pode fazer com que o nó ou a tarefa RPC trave. **Recomendações** Atualizar para a versão 1.4.0.

**Nome do Software Vulnerável e Versões Afetadas** apko versões anteriores a 1.2.7 **Descrição** A função `DiscoverKeys()` em `pkg/apk/apk/implementation.go` realiza uma asserção de tipo incondicional de chaves JWKS (JSON Web Key Set) como `*rsa.PublicKey` sem verificar o tipo da chave. Se um endpoint JWKS de repositório retornar uma chave que não seja RSA, como uma chave de Curva Elíptica (EC), a asserção não verificada causa um pânico e trava a aplicação. Isso afeta qualquer fluxo de trabalho que inicialize o banco de dados APK e busque chaves de repositório. **Recomendações** Atualize para a versão 1.2.7.

**Nome do Software Vulnerável e Versões Afetadas** apko versões 0.14.8 até 1.2.4 **Descrição** Um arquivo .apk manipulado pode instalar uma entrada de tar `TypeSymlink` cujo destino aponta para fora da raiz de compilação. Entradas subsequentes de criação de diretório ou gravação de arquivo no mesmo arquivo ou em arquivos posteriores podem atravessar esse link simbólico para acessar caminhos do host que o usuário de compilação tem permissão para gravar. O problema decorre do auxiliar `sanitizePath` em `pkg/apk/fs/rwosfs.go`, que rejeitava apenas a travessia léxica `..` e não resolvia ou recusava links simbólicos. Isso afeta métodos `DirFS` baseados em disco que passam caminhos fornecidos pelo chamador para chamadas de biblioteca padrão que seguem links simbólicos, incluindo `ReadFile()`, `WriteFile()`, `Chmod()`, `Chown()`, `Chtimes()`, `MkdirAll()`, `Mkdir()` e `Mknod()`. A primitiva primária alcançável durante a extração do tar é a cadeia `MkdirAll()` / `Mkdir()` / `WriteFile()` via `apko build-cpio` e consumidores baseados em disco, como o `melange`. **Recomendações** Atualize para a versão 1.2.5.

**Nome do Software Vulnerável e Versões Afetadas** apko (versões afetadas não especificadas) **Descrição** o apko verifica a assinatura no 'APKINDEX.tar.gz', mas não compara os pacotes '.apk' baixados individualmente com o checksum registrado no índice assinado. Embora o checksum seja analisado via `ChecksumString()` e o hash de controle do pacote baixado seja computado, esses valores não são comparados na função `getPackageImpl()`. Isso permite que pacotes incompatíveis sejam aceitos silenciosamente. Um invasor capaz de substituir as respostas de download, como por meio de um espelho comprometido, repositório HTTP ou cache de CDN envenenado, pode instalar pacotes arbitrários em imagens construídas. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha uma correção para esta vulnerabilidade.

**Nome do Software Vulnerável e Versões Afetadas** gnutls versões anteriores a 3.8.13-1.1 **Descrição** Não foram fornecidas informações detalhadas sobre a natureza dos problemas de segurança corrigidos neste pacote. **Recomendações** Atualize para a versão 3.8.13-1.1.

**Name of the Vulnerable Software and Affected Versions** tough versões anteriores a 0.22.0 **Description** Usuários remotos autenticados com autoridade de assinatura delegada podem ignorar as verificações de integridade da especificação TUF para metadados de alvos delegados e envenenar o cache de metadados local. Isso ocorre porque a função `load delegations()` não aplica as mesmas verificações de validação referentes à expiração, hash e imposição de comprimento que o caminho de metadados de alvos de nível superior. **Recommendations** Atualizar para a versão 0.22.0.

**Name of the Vulnerable Software and Affected Versions** awslabs/tough versões anteriores a 0.22.0 **Description** A verificação inadequada da unicidade da assinatura criptográfica na validação de funções delegadas permite que usuários remotos autenticados ignorem o requisito de limite de assinatura do TUF ao duplicar uma assinatura válida. Isso pode fazer com que o cliente aceite metadados de funções delegadas forjados. **Recommendations** Atualize para tough-v0.22.0 / tuftool-v0.15.0.

**Name of the Vulnerable Software and Affected Versions** awslabs/tough versões anteriores a 0.22.0 **Description** Correções incompletas de path traversal permitem que usuários remotos autenticados com autoridade de assinatura delegada escrevam arquivos fora dos diretórios de saída pretendidos. Isso ocorre porque os caminhos de gravação confiam no caminho de destino unido sem a verificação de contenção pós-resolução. O problema pode ser acionado por meio de nomes de destino absolutos em 'copy target/link target', diretórios pai com links simbólicos em 'save target' ou nomes de arquivos de metadados com links simbólicos na função `SignedRole::write`. **Recommendations** Atualizar para a versão 0.22.0.

**Name of the Vulnerable Software and Affected Versions** melange versões 0.32.0 até 0.43.3 **Description** Ao usar a flag opcional '--persist-lint-results' via 'melange lint' ou 'melange build', o software constrói caminhos de arquivos de saída juntando o parâmetro '--out-dir' com os valores `arch` e `pkgname` lidos do arquivo de controle .PKGINFO do APK. Como esses valores não são validados quanto a separadores de caminho ou sequências '..', um invasor que forneça um APK malicioso para um pipeline de lint ou build poderia fazer com que o sistema escreva um relatório de lint JSON em um caminho .json arbitrário acessível pelo processo. Isso pode levar à sobreposição de outros artefatos JSON no sistema de arquivos. Este problema afeta apenas implementações onde a flag '--persist-lint-results' é explicitamente habilitada. **Recommendations** Atualize para a versão 0.43.4. Como medida paliativa temporária, não utilize a flag '--persist-lint-results' ao realizar o lint ou build de APKs com conteúdos .PKGINFO não confiáveis. Execute o software como um usuário de baixos privilégios e restrinja as gravações a um diretório isolado para limitar o impacto.

**Name of the Vulnerable Software and Affected Versions** melange versões 0.32.0 até 0.43.3 **Description** Um invasor capaz de influenciar um arquivo de configuração, como em cenários de CI orientados por pull-request ou build-as-a-service, pode manipular a variável `pipeline[].uses` para incluir caminhos absolutos ou sequências `../`. A função `compilePipeline()` em `pkg/build/compile.go` não valida essa variável antes de passá-la para `filepath.Join()`, permitindo que o processo leia arquivos arbitrários interpretáveis em YAML fora do diretório de pipeline designado. Como o arquivo carregado é interpretado como um pipeline e seu bloco `runs:` é executado via `/bin/sh -c` dentro do sandbox de build, isso permite a execução de comandos de shell não autorizados a partir de arquivos fora da árvore, ignorando os limites de revisão padrão. **Recommendations** Atualizar para a versão 0.43.4. Executar `melange build` apenas com arquivos de configuração de fontes confiáveis. Em sistemas de CI que processam configurações fornecidas por usuários, implementar a revisão manual dos valores de `pipeline[].uses` e rejeitar qualquer um que contenha `..` ou `/` inicial.

**Name of the Vulnerable Software and Affected Versions** OpenTelemetry dotnet versões 1.13.1 até 1.15.1 **Description** Ao exportar telemetria para um back-end ou coletor via gRPC ou HTTP usando o formato OpenTelemetry Protocol (OTLP), solicitações malsucedidas (HTTP 4xx ou 5xx) fazem com que a resposta seja lida na memória sem um limite superior para o número de bytes consumidos. Isso pode levar à exaustão de memória e a uma condição de negação de serviço no aplicativo consumidor se o endpoint do back-end ou coletor configurado for controlado por um invasor ou se um invasor de rede realizar um ataque de Man-in-the-Middle (MitM) para retornar um corpo de resposta extremamente grande. **Recommendations** Atualizar para a versão 1.15.2.

**Name of the Vulnerable Software and Affected Versions** Tekton Pipelines versões 0.43.0 até 1.11.0 **Description** As políticas de verificação de recursos confiáveis comparam uma string de origem de recurso `refSource.URI` com `spec.resources[].pattern` usando a função `regexp.MatchString`. Como essa função reporta uma correspondência se o padrão for encontrado em qualquer lugar da string, padrões não ancorados podem ser burlados por strings de origem controladas por atacantes que contenham o padrão confiável como uma substring. Isso pode causar uma correspondência de política não pretendida e alterar os modos ou chaves de verificação aplicáveis. **Recommendations** Atualize o Tekton Pipelines para uma versão posterior à 1.11.0.

**Nome do Software Vulnerável e Versões Afetadas** Istio versões anteriores a 1.28.6 Istio versões anteriores a 1.29.2 **Descrição** Quando um recurso RequestAuthentication é criado com um `jwksUri` apontando para um serviço interno, o istiod realiza uma requisição HTTP GET não autenticada para essa URL sem filtrar endereços IP de localhost ou link-local. Esse comportamento pode resultar na distribuição de dados sensíveis para proxies Envoy via configuração xDS. **Recomendações** Atualizar para a versão 1.28.6. Atualizar para a versão 1.29.2. Implantar uma `ValidatingAdmissionPolicy` para impedir a criação de recursos RequestAuthentication com valores suspeitos no campo `jwksUri`, como localhost, 127.0.0.0/8, 169.254.0.0/16 e suas variantes IPv6.

**Name of the Vulnerable Software and Affected Versions** Kyverno versões anteriores a 1.16.4 **Description** O auxiliar servicecall do apiCall injeta implicitamente um cabeçalho 'Authorization: Bearer ...' usando o token de conta de serviço do controlador kyverno quando uma política não define explicitamente um cabeçalho de Autorização. Como a variável `context.apiCall.service.url` é controlada pela política, isso pode levar a um cenário de confused deputy, onde o token da conta de serviço é enviado para um endpoint controlado por um invasor. Este problema está limitado ao ClusterPolicy e ao uso de contexto global, pois as políticas de namespace são bloqueadas do uso de servicecall pelo gate `urlPath` no arquivo `pkg/engine/apicall/apiCall.go`. Um invasor com a capacidade de criar ou atualizar um ClusterPolicy ou criar uma GlobalContextEntry pode escolher a URL e os cabeçalhos da requisição para exfiltrar o token. **Recommendations** Atualizar para a versão 1.16.4. Definir um cabeçalho de Autorização explícito em políticas de servicecall para evitar a injeção implícita de tokens. Evitar o uso de servicecall para URLs arbitrárias em políticas.

**Nome do Software Vulnerável e Versões Afetadas** nimiq/core-rs-albatross versões anteriores a 1.3.0 **Descrição** Um peer não confiável pode fazer com que um validador trave. Isso ocorre quando uma mensagem de proposta tendermint assinada é publicada onde o `signer` é igual a `validators.num validators()`. A função `ProposalSender::send()` utiliza um operador de maior do que em vez de um operador de maior ou igual para a verificação de limites do assinante. Isso permite que o caso de igualdade prossiga para a função `validators.get validator by slot band(signer)`, que dispara um pânico devido a um índice fora dos limites antes que a verificação da assinatura seja executada. **Recomendações** Atualizar para a versão 1.3.0.

**Nome do Software Vulnerável e Versões Afetadas** nimiq/core-rs-albatross versões anteriores a 1.3.0 **Descrição** Um peer p2p não autenticado pode fazer com que a tarefa do manipulador de mensagens `RequestMacroChain` entre em pânico. Isso ocorre quando uma mensagem `RequestMacroChain` é enviada onde o primeiro hash de localização na cadeia principal da vítima é um hash de micro bloco em vez de um hash de macro bloco. O manipulador `RequestMacroChain::handle` seleciona o localizador baseando-se apenas se ele está na cadeia principal, então chama `get macro blocks()` e entra em pânico via `.unwrap()` quando o hash selecionado não é um macro bloco (`BlockchainError::BlockIsNotMacro`). **Recomendações** Atualizar para a versão 1.3.0.

**Nome do Software Vulnerável e Versões Afetadas** Step CA versões 0.24.0 até 0.30.0-rc3 **Descrição** Um invasor pode causar um pânico de estouro de índice no Step CA enviando um certificado de chave de atestado (AK) criado com uma extensão de Uso de Chave Estendido (EKU) vazia durante a atestação de dispositivo TPM. Durante a atestação de dispositivo TPM, o Step CA valida que o certificado AK contenha o OID de Uso de Chave Estendido tcg-kp-AIKCertificate. Um certificado criado pode incluir uma extensão EKU que decodifica para uma sequência vazia, causando um pânico no código ao acessar o primeiro elemento da fatia vazia. Esta vulnerabilidade só é alcançável quando um desafio ACME device-attest-01 com atestação de dispositivo TPM está configurado. **Recomendações** Atualize para a versão 0.30.0-rc3 ou mais recente. Se não for possível atualizar, desative ou remova quaisquer provisionadores ACME que usem a atestação de dispositivo TPM (device-attest-01).

**Name of the Vulnerable Software and Affected Versions** versões anteriores a 2.3 **Description** Ao verificar uma cadeia de certificados com restrições de DNS excluídas, essas restrições não são aplicadas corretamente aos Subject Alternative Names (SANs) de DNS curinga que diferem em maiúsculas e minúsculas. Isso afeta a validação de cadeias de certificados confiáveis emitidas por uma Autoridade Certificadora (CA) raiz no sistema ou no pool de certificados raiz especificado. **Recommendations** Atualize para uma versão anterior a 2.3.

Nome do Software Vulnerável e Versões Afetadas OpenTelemetry-Go versões 1.36.0 até 1.40.0 Descrição A implementação OpenTelemetry-Go é suscetível a um problema de amplificação de requisições remotas devido à forma como lida com os cabeçalhos baggage de múltiplos valores. Especificamente, a função `extractMultiBaggage` em `propagation/baggage.go` analisa cada valor de campo de cabeçalho `baggage` independentemente e agrega os resultados. Um invasor pode explorar isso enviando inúmeras linhas de cabeçalho `baggage`, mesmo que cada valor individual esteja dentro do limite de 8192 bytes, levando ao aumento do uso da CPU e alocações de memória. Isso pode resultar em maior latência e potenciais condições de negação de serviço. A vulnerabilidade está relacionada à análise de cabeçalhos recebidos em requisições HTTP. A função vulnerável é `extractMultiBaggage`. Recomendações Atualize para a versão 1.41.0 ou posterior.

Nome do Software Vulnerável e Versões Afetadas versões do distribution 3.0.x e anteriores, versões 2.8.x e anteriores quando o cache de descritor de blob redis e a exclusão estão ambos habilitados Descrição distribution, um toolkit para gerenciamento de conteúdo de contêiner, é suscetível a um problema de confidencialidade. Quando `storage.cache.blobdescriptor: redis` e `storage.delete.enabled: true` estão ambos habilitados, um blob excluído pode se tornar legível novamente em `repo a` após uma exclusão explícita devido à associação de escopo de repositório desatualizada no cache redis. O processo de exclusão limpa o descritor de digest compartilhado, mas não remove a associação específica do repositório, permitindo que uma solicitação subsequente `Stat` ou `Get` de `repo b` repopule o descritor e restaure o acesso em `repo a`. Isso cria uma lacuna de revogação no limite do repositório, expondo potencialmente o conteúdo excluído anteriormente. O problema envolve a interação entre as funções `linkedBlobStore.Delete`, `blobAccessController.Clear`, `cachedBlobStatter.Clear` e `repositoryScopedRedisBlobDescriptorService.Clear`. A vulnerabilidade permite que um invasor recupere o acesso ao conteúdo em `repo a` após a exclusão explícita, aproveitando a repopulação do descritor compartilhado de `repo b`. Recomendações Para as versões 3.0.x e anteriores, e versões 2.8.x e anteriores quando o cache de descritor de blob redis e a exclusão estão ambos habilitados, certifique-se de que o processo de invalidação do redis revogue o estado de escopo do repositório junto com a exclusão do link de back-end. Isso inclui remover o digest do conjunto de associação do repositório e excluir o hash do descritor de escopo do repositório para evitar que o aquecimento do repositório parceiro restaure o acesso no repositório que iniciou a exclusão.