1Seal

Existe uma falha de bypass na verificação de assinatura na função `verifyImages()`. O problema ocorre porque os resultados da verificação em cache são indexados pela string de referência da imagem, como uma tag, em vez de estarem vinculados ao digest verificado. Consequentemente, os acertos de cache permitem que o sistema ignore as verificações de assinatura e atestação. Um invasor capaz de enviar cargas de trabalho e modificar uma tag de registro pode preencher o cache com uma imagem assinada, alterar a tag para apontar para uma imagem diferente e enganar o sistema para admitir a carga de trabalho enquanto usa `mutateDigest` para fixar o digest não verificado.

Existe um problema de descompressão ilimitada na função `extractStatement()`. Atacantes remotos podem causar a negação de serviço fornecendo camadas de atestação altamente compactadas por meio de artefatos de referência de registro. Quando essas camadas de predicado gzip são descompactadas, elas podem exceder o `maxPayloadSize`, resultando em encerramentos por falta de memória (OOM kills) do controlador de admissão.

Existe um problema de descompressão ilimitada na função `FetchSignatureBlob()`. Atacantes que controlam referenciadores ou assinaturas de registro podem fornecer camadas de assinatura de notário altamente compactadas. Essas pequenas camadas gzip podem ser descompactadas além da variável `maxPayloadSize`, levando ao esgotamento de memória, encerramentos por falta de memória (OOM kills) do controlador de admissão e a consequente negação de serviço.

Existe um problema de alocação de memória ilimitada onde atacantes podem esgotar a memória da JVM ao declarar um comprimento descompactado grande em uma entrada compactada. Ao fornecer bytes manipulados para as funções `uncompress()`, `uncompressString()`, `SnappyInputStream` ou `SnappyFramedInputStream`, um atacante pode forçar alocações de até 2 GB, resultando em um OutOfMemoryError e negação de serviço.

Existe uma falha de bypass de Name Constraints quando um ponto final é utilizado em `rfc822Name` e URI. Name Constraints são um mecanismo utilizado em certificados para restringir o escopo de nomes para os quais uma Autoridade Certificadora tem permissão para emitir certificados.

Durante o fluxo de upload monolítico de blobs, o software segue um cabeçalho `Location` controlado pelo registro e reutiliza o cabeçalho `Authorization` da requisição `POST` inicial para a requisição `PUT` subsequente. Se um registro malicioso retornar um `Location` de um host diferente, as credenciais do chamador podem ser enviadas para um endpoint controlado por um invasor. Este problema ocorre na função `blobStore.completePushAfterInitialPost()` localizada em `registry/remote/repository.go`. Isso pode levar ao vazamento de credenciais e a um Server-Side Request Forgery (SSRF) do lado do cliente, onde o servidor é enganado para fazer requisições a um destino não pretendido.

Um problema existe no filtro UDP DNS quando configurado com resolução local ou remota para nomes com exatamente 255 octetos. Uma consulta com tal nome causa a terminação anormal do processo devido a uma pré-condição de tempo de execução inválida que exige que o nome da consulta seja estritamente menor que 255 octetos, o que contradiz a especificação DNS rfc1035#section-2.3.4, que permite nomes de até 255 octetos.

Um peer BLE remoto e não autenticado pode desencadear uma gravação fora dos limites (out-of-bounds write) de 2 bytes no host Bluetooth durante a remontagem de SDU L2CAP LE CoC. Isso ocorre quando a aplicação habilita a segmentação via `chan ops.alloc buf` e o pool RX escolhido possui um `user data size` menor que 2 bytes. Nesse cenário, o contador de segmentação armazenado na área user data do `net buf` é gravado fora dos limites na função `l2cap chan le recv seg()`. Isso pode resultar em corrupção de heap ou erros fatais.

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.

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.

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`.

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.

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`.

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.

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.

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.

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.

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.

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.

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.