Terrapod: aviso de segurança

Status da CVE: solicitada, aguardando atribuição. Esta descoberta é publicada como GHSA-6qrc-597p-mrp9. Após a atribuição da CVE, este repositório é renomeado CVE-YYYY-NNNNN-terrapod-PoC e este banner é substituído pelo link da CVE.

---

Resumo

A ausência de autorização na API de gerenciamento de chaves GPG no Terrapod (main @ b36d953, pós-v1.3.1) permite que qualquer principal autenticado — incluindo um usuário com apenas a função interna everyone e nenhuma concessão de capacidade, ou um token de runner com escopo — crie e exclua entradas no armazenamento de âncoras de confiança GPG de toda a plataforma, usado para verificar assinaturas de todos os provedores publicados no registro privado, por meio de POST /api/terrapod/v1/gpg-keys e DELETE /api/terrapod/v1/gpg-keys/{key_id}.

Produto

Terrapod (mattrobinsonsre/terrapod) — substituto auto-hospedado do Terraform Enterprise / HCP Terraform.

Versão testada

Commit b36d9535dedc31d85a02093d78f04da748492a2d (main), 10 commits à frente da tag de release mais próxima v1.3.1. (v1.3.2 existe como tag, mas está no branch release/v1.3 e ainda não foi mesclada em main; o bug está presente em ambos.)

CVSS v3.1 estimado

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N — 6.4 (Médio)

PR:L (não N): toda requisição ainda precisa de uma credencial válida — uma sessão, um token de API ou até mesmo um token de runner com escopo de execução runtok: — apenas não uma privilegiada. I:H/C:N/A:N: o bug permite que um chamador sem privilégios corrompa a integridade do armazenamento compartilhado de chaves de assinatura do registro (excluir chaves legítimas, inserir as suas próprias), mas não divulga por si só material de chave secreta (chaves privadas nunca são serializadas em nenhuma resposta) nem derruba o serviço.

Detalhes

services/terrapod/api/routers/gpg_keys.py implementa CRUD para linhas de GPGKey — as chaves públicas em formato ASCII-armored que o Terrapod confia para verificar o SHA256SUMS.sig destacado em cada versão de provedor publicada no registro privado (services/terrapod/services/registry_provider_service.py:191-201, _verify_and_store_shasums_signature). Todas as rotas do router são protegidas apenas por Depends(get_current_user) — ou seja, "algum principal autenticado" — sem nenhuma verificação de função ou capacidade:

• create_gpg_key_endpoint — services/terrapod/api/routers/gpg_keys.py:104-130
• list_gpg_keys_endpoint — gpg_keys.py:133-146
• show_gpg_key_endpoint — gpg_keys.py:149-166
• revoke_gpg_key_endpoint — gpg_keys.py:168-193
• delete_gpg_key_endpoint — gpg_keys.py:195-213

As funções de serviço subjacentes (services/terrapod/services/gpg_key_service.py:144 create_gpg_key, :316 delete_gpg_key) não recebem nenhum argumento de chamador/propriedade — GPGKey não tem coluna de namespace ou proprietário (_gpg_key_to_jsonapi codifica fixamente "namespace": "default"; o campo namespace aceito na criação é analisado pelo modelo de requisição, mas nunca é repassado). O conjunto de chaves é uma lista global e compartilhada para toda a plataforma.

Compare isso com todos os outros recursos de plataforma de propriedade administrativa no mesmo código — tokens.py, roles.py, vcs_connections.py, role_assignments.py — que protegem rotas de mutação atrás de require_admin ou de uma verificação explícita de propriedade bound_to == user.email or is_admin. gpg_keys.py é o único router em api/routers/ que gerencia um recurso crítico de segurança de toda a plataforma sem nada disso.

Cadeia de impacto: get_gpg_key_by_key_id() (registry_provider_service.py:195) faz uma busca global e sem escopo — qualquer chave já registrada, por qualquer pessoa, é uma âncora de confiança válida para qualquer publicação de provedor (isso é intencional para o registro de chaves de publicador em autoatendimento — a mensagem de erro inclusive diz add it via /api/terrapod/v1/gpg-keys first). Como o registro não tem verificação de autenticação, e a exclusão também não tem:

1. Qualquer usuário autenticado (ou um token de runner vazado/observado, que require_non_runner existe especificamente para manter fora de "endpoints de criação e gerenciamento de recursos", conforme sua própria docstring em services/terrapod/api/dependencies.py:387-400, mas que este router nunca usa) pode excluir a chave de assinatura registrada de qualquer outro tenant, quebrando a verificação de assinatura de todas as versões de provedor que aquele tenant já publicou — um ataque de integridade entre tenants sem nenhuma relação com o namespace alvo.
2. O mesmo chamador pode registrar uma nova chave confiável, expandindo o conjunto compartilhado de âncoras de confiança da plataforma sem nenhuma barreira além de ter qualquer credencial.

A própria suíte de testes do projeto documenta essa lacuna sem questioná-la — services/tests/api/test_gpg_keys.py constrói seus testes de caminho feliz de criação/exclusão/revogação com AuthenticatedUser(roles=["everyone"], ...) (veja _user(), linha 23, usado em todo TestCreate/TestDelete/TestRevoke) e afirma 201/204 para esse usuário sem privilégios — ou seja, os testes afirmam o comportamento vulnerável como correto, apenas nunca foram escritos para perguntar "o everyone deveria ter permissão para fazer isso?"

Prova de Conceito

Verificado dinamicamente contra a aplicação real (Postgres + Redis reais por meio do próprio harness de testes de integração docker-compose.test.yml do projeto — sem mocks, sem modificações não relacionadas no código da aplicação):

1. Escreveu services/tests/integration/test_gpg_key_missing_authz_poc.py:
   • test_everyone_role_user_can_delete_admins_signing_key — um admin registra uma chave pública PGP RSA-2048 real via POST /api/terrapod/v1/gpg-keys (201, presença confirmada no Postgres), então um segundo usuário autenticado apenas com roles=["everyone"] (sem admin, sem concessões de capacidade) envia DELETE /api/terrapod/v1/gpg-keys/{key_id} e isso é bem-sucedido (204); a linha é confirmada como removida do Postgres depois.
   • test_everyone_role_user_can_register_new_trusted_key — o mesmo usuário sem privilégios registra uma chave totalmente nova via POST /api/terrapod/v1/gpg-keys (201).
2. Construiu a imagem de teste e a executou contra a infraestrutura real:
   root@kitploit:~

   docker build -f docker/Dockerfile.test -t terrapod-test:local .
   docker compose -f docker-compose.test.yml run --rm test \
     pytest tests/integration/test_gpg_key_missing_authz_poc.py -v -m integration
   

   Resultado: — ambas as asserções (a exclusão não autorizada sendo bem-sucedida e a linha realmente desaparecendo do banco de dados real) se confirmaram. Captura de tela: .

Impacto

Qualquer usuário autenticado de uma instância do Terrapod — independentemente de função, acesso a workspace ou permissões de registro, até a função interna sem privilégios everyone ou um token de runner com escopo de uma única execução — pode adulterar o armazenamento compartilhado de âncoras de confiança GPG da plataforma: excluir a chave de assinatura registrada de outra equipe (quebrando a verificação de assinatura do terraform init para todas as versões de provedor que ela já publicou, em toda a plataforma) e/ou adicionar novas chaves ao conjunto confiável. Isso mina a garantia de cadeia de suprimentos de "registro privado de módulos + provedores assinados com GPG" que o projeto anuncia como recurso de destaque, sem exigir nenhum privilégio de workspace ou registro por parte do atacante.

Fraquezas

• CWE-862: Ausência de Autorização
• CWE-284: Controle de Acesso Impróprio

Remediação

Adicione uma barreira de capacidade/função às rotas de mutação em services/terrapod/api/routers/gpg_keys.py, seguindo o padrão já usado por tokens.py/roles.py/vcs_connections.py — por exemplo, Depends(require_admin) em create_gpg_key_endpoint, delete_gpg_key_endpoint e revoke_gpg_key_endpoint (a revogação é protegida separadamente ao exigir um certificado válido de autorrevogação, mas ainda assim não deveria ser acessível por um chamador arbitrário para chaves de outros tenants). list/show têm risco menor (os blocos armor são chaves públicas por design), mas provavelmente também deveriam exigir pelo menos require_non_runner por consistência. Considere também introduzir uma coluna de namespace/proprietário em GPGKey se chaves de publicador por namespace em autoatendimento forem o modelo pretendido, para que um proprietário de namespace possa gerenciar apenas a(s) sua(s) própria(s) chave(s) em vez da única lista global.

Crédito: Dostxodjayev Abdullox

Canal de relato: Conforme o SECURITY.md, não abra uma issue pública. Use o relato privado de vulnerabilidades do GitHub: acesse https://github.com/mattrobinsonsre/terrapod/security/advisories/new, clique em "Report a vulnerability" e preencha a descrição, os passos para reproduzir e as versões afetadas. (Se o PVR não estiver disponível, a política diz para enviar um e-mail diretamente ao mantenedor.)