Laura Pardo

O utilitário `foreman-tail` é suscetível a injeção de comandos de SO resultante da implementação insegura do comando `eval`. O script incorpora argumentos fornecidos pelo usuário em uma string executada pelo `eval` para expandir caminhos de arquivos sem a devida sanitização ou aspas. Isso permite que um invasor local utilize metacaracteres de shell, como `;`, `&` ou `|`, para executar comandos arbitrários no sistema.

Um bypass de autenticação existe no endpoint de API '/unattended/provision' devido a uma falha de lógica semântica em `host verifier.rb`. A aplicação verifica o estado do token de provisionamento no banco de dados em vez de verificar sua presença na requisição HTTP recebida. Consequentemente, se um host estiver em processo de provisionamento e possuir um token não expirado no banco de dados, o método `valid host token?()` retorna verdadeiro, permitindo o acesso ao template de kickstart mesmo que nenhum token seja fornecido na URL.

Falhas de injeção de comando de sistema operacional existem nas tarefas `foreman-rake db:dump` e `db:import dump`. A aplicação não sanitiza adequadamente a entrada fornecida pelo usuário no parâmetro `destination` durante backups e no parâmetro `file` durante importações antes de passá-los para uma chamada `system()` do Ruby para execução. Um invasor com permissões para executar o `foreman-rake`, como por meio de uma configuração sudo restrita, pode anexar comandos de shell maliciosos aos caminhos de arquivo fornecidos.

Uma injeção de comando é possível no Hammer CLI e no componente Railties (Ruby on Rails) distribuído com o Satellite. O problema ocorre porque a variável de ambiente `$EDITOR` é interpolada de forma insegura na função `system()` do Ruby. Ao passar uma única string interpolada para `system()`, a aplicação invoca um shell do sistema (/bin/sh) que interpreta metacaracteres de shell, como `;`, `|` e `&`.

Uma falha de injeção de comando existe no endpoint da API do Red Hat Satellite '/api/v2/job invocations'. O problema ocorre quando um modelo de trabalho possui a propriedade `effective user` marcada como overridable: true, pois a aplicação não sanitiza adequadamente a entrada `effective user` fornecida durante a requisição da API. Isso permite que um invasor com permissões para executar modelos de trabalho injete comandos de shell arbitrários no parâmetro `effective user`, que são executados na infraestrutura de destino com os privilégios do usuário de execução. A injeção ocorre durante a instanciação do ambiente de execução do trabalho pelo servidor Satellite e é independente da lógica do modelo de trabalho ou playbook.

Uma falha de injeção de comando existe na tarefa `foreman-rake errors:fetch log`. O parâmetro `request id` é passado para um comando de sistema subjacente, normalmente o `grep`, sem a neutralização adequada do shell. Um invasor com permissões de sudo para executar esta tarefa rake pode injetar metacaracteres de shell, como `;`, `"` ou `|`, para burlar o comando pretendido e executar código arbitrário.

Uma falha foi encontrada na lógica de inicialização do `foreman-rake` localizada em `/usr/share/foreman/config/settings.rb`. O problema decorre de um padrão de código onde os dados de configuração são processados por duas camadas executáveis distintas, criando uma cadeia de execução de múltiplos estágios. Isso permite a Injeção de Template no Lado do Servidor (SSTI)—onde um invasor injeta templates maliciosos que são executados no servidor—e a desserialização insegura—onde dados não confiáveis são usados para abusar da lógica de um aplicativo para executar código arbitrário. Isso pode resultar na execução remota de código, comprometimento total da infraestrutura e risco à cadeia de suprimentos.

Um problema de SQL injection existe no Red Hat Satellite Katello Registry Proxy devido à sanitização inadequada de parâmetros de entrada usados em consultas ao banco de dados dentro do `RegistryProxiesController`. Especificamente, as funções `check blob push org label()` e `get matching products from org()` recebem rótulos fornecidos pelo usuário a partir do caminho da requisição e os interpolam em fragmentos de SQL bruto. Isso permite que um usuário com apenas a permissão `create personal access tokens` explore a falha, independentemente de ter uma Organização ou Localização atribuída.

Existe uma falha de bypass de autorização no `RegistryProxiesController` do Katello devido a um fluxo de execução contínuo (fall-through) no filtro `registry authorize`. Embora a aplicação identifique requisições não autorizadas e acione uma resposta de erro através da função `unauthorized()`, ela falha em interromper a execução do caminho de código atual devido à ausência de uma instrução de retorno. Essa falha no fluxo de controle permite que a aplicação prossiga para a lógica de negócio e filtros de validação de banco de dados, revelando o estado interno por meio de respostas diferenciais. Um invasor sem privilégios pode explorar isso para enumerar Usuários, Organizações e Produtos válidos em toda a instância.

Uma falha existe no campo `pod spec override` do grupo de contêineres devido a uma lista de bloqueio incompleta que restringe apenas o `automountServiceAccountToken`. Isso permite a injeção de `initContainers`, substituições de `serviceAccountName` e volumes de token de conta de serviço projetados. Um administrador da plataforma AAP pode explorar isso para escalar privilégios para acesso ao nível de namespace do OpenShift e exfiltrar segredos do namespace.

Existe um problema onde a extensão armazena de forma insegura a chave da API do Google Gemini em texto simples dentro do arquivo de configuração do usuário e a grava em arquivos de log de saída. Isso permite que um invasor local ou malware executado com privilégios de usuário leia a chave da API, levando potencialmente ao uso não autorizado da cota de API do usuário.

Uma falha de injeção de comando existe no `AnsiblePlaybookRunProvider`. Um invasor pode criar um nome de arquivo de playbook malicioso contendo caracteres especiais que não são devidamente sanitizados. Quando o playbook é executado, isso permite a execução de código arbitrário com os privilégios do usuário que executa o VS Code, podendo resultar no comprometimento total do sistema, exfiltração de dados sensíveis, modificação de arquivos de projeto e perda permanente de dados.

Existe um problema devido ao manuseio inadequado das configurações `ansible.executionEnvironment.containerOptions` e `ansible.executionEnvironment.volumeMounts`, o que permite a injeção de separadores de shell. Isso pode ser acionado automaticamente durante a inicialização do Language Server ou manualmente ao executar um playbook. A exploração bem-sucedida permite a execução remota de código (RCE) na máquina da vítima com os privilégios do usuário do Visual Studio Code, podendo resultar no comprometimento total do sistema.

Uma falha de injeção de comando existe onde a extensão não valida adequadamente a entrada do usuário como um caminho de arquivo na configuração `ansible.python.activationScript`. Esta configuração é destinada a scripts de ativação de ambiente virtual. Um invasor remoto pode explorar isso induzindo um usuário a abrir ou executar um projeto especialmente criado, permitindo a execução de comandos não autorizados com os privilégios do aplicativo Visual Studio Code.

Uma falha de path traversal (travessia de diretório) existe no servidor Ansible Lightspeed Model Context Protocol (MCP). Este problema permite que um invasor manipule um agente de IA por meio de injeção indireta de prompt, que é uma técnica onde instruções maliciosas são incorporadas em dados que a IA processa. Essa manipulação pode forçar o servidor a gravar arquivos em locais não autorizados no sistema do usuário, potencialmente expondo informações sensíveis do host e permitindo a execução de comandos maliciosos, o que pode levar ao comprometimento total do sistema.

Dois mecanismos de log distintos no software podem expor dados sensíveis de sessão e autenticação. Um mecanismo registra identificadores de sessão, que funcionam como credenciais de autenticação, em nível informativo. Um segundo mecanismo, ativo quando o log de depuração (debug) está habilitado, não sanitiza completamente os cabeçalhos de requisição HTTP, resultando no registro em texto claro de chaves de API e tokens de autorização. Isso leva a uma quebra de confidencialidade onde dados sensíveis são armazenados em texto simples nos logs do container, o que aumenta o risco se os logs forem enviados para uma plataforma centralizada.

Um problema de gerenciamento de sessão no MCP Server permite que invasores não autenticados sequestrem sessões administrativas ativas. Isso ocorre porque o servidor armazena incorretamente em cache as conexões de clientes autenticados, confia em IDs de sessão não secretos sem revalidar os tokens de autenticação e registra IDs de sessão recém-criados em logs padrão. A exploração bem-sucedida pode levar à escalada de privilégios e execução de código em toda a infraestrutura.

Existe um problema devido à expiração insuficiente da sessão, permitindo que um atacante remoto mantenha acesso persistente à instância. Se um token de acesso OAuth (Open Authorization) válido for exfiltrado antes de um usuário encerrar a sessão, o atacante poderá continuar a se autenticar e a acessar dados sensíveis. Isso ocorre porque a aplicação não invalida o token no backend, deixando-o ativo até a sua expiração natural. Isso pode resultar em acesso de leitura não autorizado a recursos como inventários, playbooks e dados de configuração.

Os endpoints de conversa da API do Ansible Lightspeed, que gerenciam interações de chat com IA, não confirmam adequadamente se um identificador de conversa corresponde ao usuário autenticado. Isso permite que um invasor com credenciais válidas acesse ou modifique conversas pertencentes a outros usuários, potencialmente expondo dados sensíveis e permitindo a manipulação não autorizada de saídas geradas por IA. Os endpoints de API afetados são os endpoints de conversa. O parâmetro vulnerável é o identificador de conversa.

Foi encontrada uma falha no http-proxy-agent, na qual ele passa uma opção de autenticação para o construtor Buffer sem a devida sanitização. Isso pode resultar em uma negação de serviço (DoS) devido ao uso de todos os recursos de CPU disponíveis e na exposição de dados por meio de um vazamento de memória não inicializada em configurações nas quais um invasor poderia enviar entradas digitadas para o parâmetro `auth`.