Chris Meyers

Existe uma falha onde o `host config key` (segredo de callback de provisionamento) é exposto a usuários que possuem apenas a permissão de leitura `view jobtemplate`, tanto na representação da API do modelo de trabalho quanto no fluxo de atividades. Além disso, quando o controlador é implantado atrás do gateway AAP com uma lista de permissões de proxy vazia, o endpoint de callback de provisionamento confia no cabeçalho `X-Forwarded-For` fornecido pelo cliente para determinar o host de chamada. Um invasor remoto não autenticado ou com privilégios mínimos pode usar o segredo vazado e falsificar o cabeçalho `X-Forwarded-For` para corresponder a qualquer host no inventário do modelo de trabalho, permitindo a execução do modelo contra hosts gerenciados arbitrários usando as credenciais do modelo. Isso resulta em escalonamento de privilégios e execução remota de código nos hosts gerenciados.

Um problema de controle de acesso inadequado existe no endpoint '/api/v2/config/', que é protegido apenas pela permissão `IsAuthenticated`. Isso permite que qualquer usuário autenticado acesse o objeto `license info`, que contém dados sensíveis como `account number`, `subscription id`, `pool id`, `sku`, `support level` e `instance counts`. Embora um gate de superusuário ou auditor restrinja o acesso a `project base dir`, `project local paths` e `custom virtualenvs`, ele não abrange o `license info`. Essa exposição pode ser utilizada para reconhecimento de dimensionamento de infraestrutura e ataques de engenharia social contra o suporte da Red Hat.

A função `HostList.list()` captura exceções genéricas e retorna a string de erro literalmente. Um usuário autenticado pode explorar isso por meio do parâmetro `host filter` para disparar um Django FieldError, que vaza o grafo de relação completo do modelo Host e acessores reversos internos, ou um PostgreSQL DataError, que vaza strings de erro brutas do banco de dados. Isso pode ser alcançado usando primitivas como `credential search=x` para despejar o esquema ORM ou `name regex=[bad` para refletir erros do PostgreSQL.

A função `to internal value()` em `StringListPathField` chama `os.path.exists()` utilizando caminhos ilimitados fornecidos pelo usuário. Isso permite que um superusuário de locatário determine a existência de caminhos absolutos arbitrários no pod controller-web ao observar a diferença entre as respostas HTTP 200 e 400. Isso pode ser usado para confirmar a presença de arquivos sensíveis, como `/etc/tower/SECRET KEY`, tokens de conta de serviço do Kubernetes, sockets do receptor e pontos de montagem de ConfigMap. Este problema é principalmente impactante em ambientes gerenciados do Ansible Automation Platform (AAP), onde o administrador do locatário não é o administrador do host.

A whitelist de AST do Jinja para modelos de notificação inspeciona apenas nós Getattr estáticos. Isso permite que subscripts dinâmicos, como `job['job'+' env']`, e gating condicional, como `{% if job.id > 100 %}`, ignorem tanto a verificação de AST quanto o processo de test-render. Em tempo de execução, o ramo condicionado é executado e as exceções gravam tracebacks completos no corpo da notificação, que é enviado via POST para uma URL de webhook controlada por um invasor. Esse processo vaza informações sensíveis, incluindo caminhos de instalação, versão do Python e números de linhas do código-fonte.

Existe uma falha de validação no `LaunchConfigurationBaseSerializer.scm branch` onde a verificação de traços iniciais no `validate scm branch()` está ausente. Isso permite que a variável `scm branch` aceite entradas maliciosas, como `--upload-pack=/bin/id`. Embora uma verificação de defesa em profundidade em `jobs.py:1502` atualmente impeça a execução ao gerar um `ValueError`, a falta de validação no nível da API significa que o sistema depende exclusivamente de uma proteção na camada de tarefa. Se essa proteção for removida ou refatorada, isso poderá levar à Execução Remota de Código (RCE), situação em que um invasor pode executar comandos arbitrários na máquina hospedeira.

A função `build args()` dentro de `RunAdHocCommand` anexa incorretamente a variável `limit` como um argumento posicional simples em vez de usar a flag `-l`. Isso permite que um valor de `limit` começando com hífen seja interpretado como uma opção de CLI do ansible. Atualmente, isso se limita a flags de curto-circuito, como `--version` e `--help`, pois o elemento injetado desloca o argumento posicional de padrão obrigatório.

O `URLModificationMiddleware` resolve buscas de URLs nomeadas contra `Model.objects` não filtrados antes da aplicação do Controle de Acesso Baseado em Função (RBAC). Como o shim de resposta 403 para 404 apenas reescreve respostas 403, o caminho para uma falha de `pk=0` retorna uma string de detalhe 404 diferente. Essa diferença entre "Not found." e "No <Model> matches..." permite que um invasor determine se um recurso nomeado, como organização, credencial, inventário ou host, existe em qualquer lugar da plataforma, permitindo a enumeração de nomes de host internos entre locatários (cross-tenant).

A view `JobJobEventsChildrenSummary` não possui um modelo ou modelo pai definido, fazendo com que a função `ModelAccessPermission.check get permissions()` retorne True para qualquer usuário autenticado. Como a view utiliza `get object or 404(Job, pk)` sem implementar as verificações de permissão em nível de objeto do Django Rest Framework (DRF), um usuário autenticado sem privilégios pode acessar a estrutura da árvore de eventos e o status `event processing finished`. Além disso, isso permite a enumeração de IDs de Job em toda a plataforma através de um oráculo 200/404, onde a resposta do servidor indica se um ID específico existe. Isso ocorre enquanto o endpoint irmão '/jobs/{id}/job events/' aplica as permissões corretamente.

Uma falha foi encontrada no plugin de credenciais do HashiCorp Vault do AAP Controller. Quando uma credencial de busca de segredos do HashiCorp Vault com autenticação `kubernetes role` é testada, a função `kubernetes auth()` em `awx plugins/credentials/hashivault.py` lê o token de conta de serviço do Kubernetes do pod do controlador e o envia para uma URL controlada por um invasor. Um invasor autenticado com privilégios de criação de credenciais pode exfiltrar esse token, obtendo acesso à API do Kubernetes aos namespaces do plano de controle. Esse acesso permite operações completas de CRUD (Criação, Leitura, Atualização e Exclusão) de pods e a leitura de segredos, incluindo credenciais de banco de dados e a `SECRET KEY` do Django.

O servidor Event-Driven Ansible (EDA) contém uma falha no `ExternalEventStreamViewSet` devido a controles de acesso permissivos. O sistema confia exclusivamente no cabeçalho HTTP `Subject` para autenticação mTLS (mutual Transport Layer Security)—um processo onde cliente e servidor verificam os certificados um do outro—sem confirmar que o cabeçalho foi enviado por um proxy confiável. Além disso, o corpo da resposta de erro 403 vaza o Distinguished Name esperado do certificado. Um invasor capaz de alcançar o endpoint da API com um cabeçalho `Subject` falsificado pode injetar eventos arbitrários em fluxos de eventos protegidos para disparar ações de automação subsequentes.

Uma falha na configuração do proxy Envoy do AAP Gateway permite que um invasor remoto não autenticado ignore a autenticação mTLS. A rota não-mTLS para fluxos de eventos EDA não remove o cabeçalho HTTP `Subject` das requisições do cliente. Ao injetar um cabeçalho `Subject` falsificado que corresponda ao Nome Distinto (DN) de um certificado de cliente legítimo, um invasor pode injetar eventos arbitrários em fluxos de eventos EDA protegidos.

Uma falha de autorização foi encontrada na API de websocket. O endpoint '/api/eda/ws/ansible-rulebook' não verifica as permissões do usuário ao processar mensagens do Worker. Isso permite que qualquer usuário autenticado envie uma mensagem forjada com um `activation id` arbitrário para receber credenciais em texto simples associadas a essa ativação, incluindo tokens OAuth, senhas de cofre (vault) e chaves SSH.

Um problema de injeção de comando existe na API de importação de funções legadas (v1), onde a função `do git checkout()` interpola nomes de referência git não sanitizados, como nomes de branches ou tags, em comandos de shell executados via `subprocess.run()` com `shell=True`. Um usuário autenticado com controle sobre um repositório git pode usar metacaracteres de shell em um nome de branch ou tag para alcançar a execução remota de código no trabalhador pulp. Este endpoint só está acessível quando a variável `GALAXY ENABLE LEGACY ROLES` está definida como True.

Foi identificada uma falha no Ansible aap-gateway, na qual solicitações simultâneas manipuladas pelo serviço grpc do gateway podem resultar em problemas de concorrência devido a condições de corrida nas solicitações contra o proxy. Esse problema potencialmente permite que um usuário com menos privilégios obtenha o JWT de um usuário com mais privilégios, possibilitando o comprometimento do servidor. Uma sessão de usuário ou dados confidenciais podem ficar vulneráveis.