Jake-Ciolek

Uma imagem maliciosamente criada pode causar uma condição de Negação de Serviço (DoS). Quando um contêiner é criado a partir de tal imagem, ocorre a exaustão de memória, resultando em um encerramento por falta de memória (Out Of Memory - OOM) do processo containerd. Esta ação torna a API de tempo de execução do contêiner indisponível e pode interromper clientes, incluindo o Docker Engine ou componentes do plano de controle do Kubernetes.

Spinnaker updated the URL validation logic for user input to sanitize URLs for clouddriver. However, Java URL objects do not correctly handle underscores during parsing, leading to a bypass of a previous issue. This impacts both clouddriver and Orca fromUrl expression handling. The issue stems from a flaw in how Java URL objects process underscores within URLs, effectively circumventing the intended URL validation.

O Argo CD está suscetível a negação de serviço através de requisições de API maliciosas. Especificamente, quando um `webhook.bitbucketserver.secret` não está configurado, o endpoint `/api/webhook` falha ao receber um payload malformado do Bitbucket Server onde o campo `repository.links.clone` não é um array. Uma única requisição não autenticada pode fazer com que o servidor da API entre em um estado CrashLoopBackOff, e atingir todas as réplicas pode resultar em uma indisponibilidade completa da API. O problema origina-se de uma assertiva de tipo insegura dentro do arquivo `webhook.go`, que entra em panic quando o tipo de array esperado não é atendido. Uma prova de conceito (PoC) demonstra que enviar um payload JSON manipulado para o endpoint `/api/webhook` pode acionar esse panic e derrubar o servidor.

O Argo CD, uma ferramenta de entrega contínua GitOps declarativa para Kubernetes, está suscetível a um problema de negação de serviço. Quando o `webhook.azuredevops.username` e o `webhook.azuredevops.password` não estão definidos na configuração padrão, o endpoint `/api/webhook` faz falhar todo o processo `argocd-server` ao receber um evento Push do Azure DevOps com um array JSON `resource.refUpdates` vazio. Isso ocorre porque o código tenta acessar o primeiro elemento (`[0]`) do slice `resource.refUpdates` sem verificar seu comprimento, levando a um panic de índice fora do intervalo. Uma única requisição HTTP POST não autenticada para o endpoint `/api/webhook` é suficiente para encerrar o processo. O código vulnerável está localizado em `util/webhook/webhook.go` por volta da linha 147, especificamente ao analisar as informações de revisão. O problema é acionado quando o array `refUpdates` está vazio, causando um panic durante o acesso ao slice.

O Argo CD está suscetível a requisições de API maliciosas que podem levar a uma negação de serviço, causando a falha do servidor de API e interrompendo o serviço para usuários legítimos. Especificamente, o endpoint `/api/webhook` é vulnerável quando o `webhook.gogs.secret` não está configurado. Neste cenário, receber um evento de push do Gogs com um campo JSON `commits[].repo` ausente ou nulo causa a falha do processo `argocd-server`. A função `affectedRevisionInfo` carece de validação adequada da estrutura de dados para tipos de eventos de webhook, permitindo que um atacante explore isso enviando dados manipulados. A vulnerabilidade reside na função `Handler`, que analisa mensagens do tipo webhook com base nos parâmetros `header` e `body`. A função `Parse` desserializa mensagens do tipo JSON sem validação estrita. Um atacante pode enviar repetidamente requisições não autenticadas para o endpoint `/api/webhook` para causar uma negação de serviço.

Nome do Software Vulnerável e Versões Afetadas: Versões do Helm anteriores à 3.18.5 Descrição: O Helm, um gerenciador de pacotes para Charts do Kubernetes, está suscetível a uma vulnerabilidade de negação de serviço. Um arquivo JSON Schema manipulado pode fazer com que o Helm esgote a memória disponível, levando a um encerramento por falta de memória (OOM). Isso ocorre quando o campo `$ref` em ` values.schema.json ` aponta para um dispositivo ou arquivo problemático, como `/dev/zero`. Recomendações: As versões do Helm anteriores à 3.18.5 devem ser atualizadas para a versão 3.18.5 ou posterior. Garanta que todos os Charts do Helm carregados no Helm não possuam nenhuma referência `$ref` apontando para `/dev/zero`.

Nome do Software Vulnerável e Versões Afetadas: Versões do Helm anteriores à 3.18.5 Descrição: O Helm é um gerenciador de pacotes para Charts do Kubernetes. Uma validação inadequada de tipo ao analisar os arquivos `Chart.yaml` e `index.yaml` pode levar a um panic. Este problema impacta a validação YAML onde um arquivo `Chart.yaml` possui um mantenedor `null` ou onde o `child` ou `parent` de um `import-values` de dependências pode ser analisado como algo diferente de uma string, causando um panic no `helm lint`. Além disso, uma entrada vazia na lista de versões do chart dentro de um `index.yaml` pode causar um panic no Helm. Recomendações: Atualize para a versão 3.18.5 ou posterior do Helm. Garanta que os arquivos YAML estejam formatados como o Helm espera antes de processá-los com o Helm.

Nome do Software Vulnerável e Versões Afetadas: Versões do Helm anteriores à 3.18.4 Descrição: Um arquivo `Chart.yaml` especialmente criado, juntamente com um arquivo `Chart.lock` vinculado especificamente, pode levar à execução local de código quando as dependências são atualizadas. Campos em um arquivo `Chart.yaml` podem ser manipulados para causar execução caso o conteúdo esteja em um arquivo que é executado, como um arquivo `bash.rc` ou script shell. Se o arquivo `Chart.lock` for um link simbólico para um desses arquivos, a atualização das dependências escreverá o conteúdo do arquivo lock no arquivo vinculado, levando à execução indesejada. Este problema ocorre quando as dependências são atualizadas, por exemplo, ao executar `helm dependency update`. Recomendações: Para versões do Helm anteriores à 3.18.4, certifique-se de que o arquivo `Chart.lock` em um chart não seja um link simbólico antes de atualizar as dependências. Atualize para o Helm v3.18.4 para resolver o problema.

Nome do Software Vulnerável e Versões Afetadas: Versões do Helm anteriores à 3.17.3 Descrição: Um arquivo JSON Schema dentro de um chart pode ser criado com uma cadeia de referências profundamente aninhada, levando à recursão do parser que pode exceder o limite de tamanho da pilha e causar um estouro de pilha. Este problema foi descoberto por um contribuidor do Helm. Recomendações: Para versões anteriores à 3.17.3, atualize para o Helm v3.17.3 para resolver o problema. Como solução alternativa temporária, certifique-se de que o JSON Schema dentro de quaisquer charts carregados pelo Helm não possua um grande número de referências aninhadas, evitando especificamente arquivos maiores que 10 MiB.

Nome do Software Vulnerável e Versões Afetadas: Versões do Helm anteriores a 3.17.3 Descrição: Um arquivo de chart especialmente construído pode fazer com que o Helm esgote sua memória, levando a uma terminação por falta de memória. Isso ocorre quando o arquivo se expande para um tamanho significativamente maior quando descompactado em comparação ao compactado, com uma diferença de mais de 800 vezes. O problema está relacionado à maneira como o Helm carrega arquivos de chart. Recomendações: Para versões anteriores a 3.17.3, atualize para o Helm v3.17.3 para resolver o problema. Como medida temporária de contorno, garanta que quaisquer arquivos de chart carregados pelo Helm não contenham arquivos grandes o suficiente para fazer com que o Cliente ou SDK do Helm esgote a memória disponível, levando a uma terminação.

Nome do software vulnerável e versões afetadas: Versões do Argo CD anteriores à 2.11.6 Versões do Argo CD anteriores à 2.10.15 Versões do Argo CD anteriores à 2.9.20 Descrição: O problema está relacionado a um invasor não autenticado que envia uma carga JSON grande e especialmente criada para o endpoint “/api/webhook”, causando alocação excessiva de memória que leva à interrupção do serviço ao acionar um kill por falta de memória (OOM). Isso representa um alto risco para a disponibilidade das implantações do Argo CD. A vulnerabilidade pode ser explorada enviando-se uma solicitação maliciosa de grande porte com cabeçalhos, como “X-GitHub-Event: push”, que fará com que o ArgoCD comece a alocar memória para analisar a solicitação recebida. Recomendações: Para versões anteriores à 2.11.6, atualize para a versão 2.11.6 ou posterior. Para versões anteriores à 2.10.15, atualize para a versão 2.10.15 ou posterior. Para versões anteriores à 2.9.20, atualize para a versão 2.9.20 ou posterior. Como solução alternativa temporária, considere restringir o acesso ao endpoint “/api/webhook” para minimizar o risco de exploração. Aplique um limite ao tamanho da solicitação que está sendo analisada para evitar alocação excessiva de memória.

O problema está relacionado a uma vulnerabilidade de variável não inicializada quando o Helm analisa arquivos YAML de índice e de plug-ins que não contêm o conteúdo esperado. Isso pode causar um erro grave no Helm quando um arquivo `index.yaml` ou o arquivo `plugin.yaml` de um plug-in não contém nenhum metadado. A vulnerabilidade é encontrada no Helm SDK ao usar as funções `LoadIndexFile` ou `DownloadIndexFile` no pacote `repo` ou a função `LoadDir` no pacote `plugin`. Para o cliente Helm, isso afeta funções relacionadas à adição de um repositório e todas as funções do Helm caso um plugin malicioso seja adicionado.