FlawOpen

flawopen.com/Diretório/226

● CWE-367 / CWE-829 · Alta
Pesquisa · FlawOpen

Marimo GHSL-2026-226: TOCTOU no fluxo de teste de versão

Uma corrida de timestamp no mesmo segundo permitia que uma atualização de pull request passasse pela aprovação de teste do mantenedor e chegasse aos jobs de publicação no TestPyPI e no npm. O workflow vulnerável foi removido; não foi atribuído CVE.

💡 Explicação em Linguagem Simples (ELI5)

Um responsável pelo laboratório aprova uma amostra, mas o laboratório confere apenas o segundo do relógio. Se alguém trocar a amostra naquele mesmo segundo, a substituta parece aprovada. O workflow do Marimo fez isso com um commit de pull request e levou o pacote resultante aos jobs de publicação.

Conceitos Centrais e Termos

TOCTOU
Time-of-check to time-of-use: um recurso muda depois da verificação de segurança e antes de ser usado.
Publicação via OIDC
Um job de CI troca um token de identidade do GitHub Actions por credenciais temporárias no registro de pacotes, sem armazenar uma senha de longa duração.
Artefato do workflow
Conjunto de arquivos transferido entre jobs do GitHub Actions. Um job posterior deve tratar como entrada não confiável artefatos de workflows não confiáveis.
GHSL-2026-226
Identificador do advisory do GitHub Security Lab para esta falha no workflow do Marimo. O advisory não atribuiu CVE.
CWE-367 / CWE-829
O advisory identifica uma corrida de verificação e uso e a execução de funcionalidade de uma esfera de controle não confiável.

Mapeamentos de frameworks

Fluxo de Ataque Passo a Paso

Passo 1

Um mantenedor autoriza uma versão de teste

Um mantenedor comenta em um pull request para iniciar o workflow de teste de versão do Marimo. A autorização deveria valer para o estado do pull request que foi revisado.

Passo 2

O head do pull request muda no mesmo segundo

O workflow compara pushed_at do repositório com created_at do comentário após converter ambos para segundos inteiros. Um push no mesmo segundo resulta em valores iguais.

Passo 3

A verificação vulnerável aceita a igualdade

O workflow removido rejeitava apenas valores de pushed_at estritamente maiores que o horário do comentário. A igualdade passava e o commit atualizado era registrado.

Passo 4

Código não confiável cria artefatos de pacote

O job fazia checkout desse commit e executava actions e scripts de build controlados pelo repositório. Os resultados eram enviados como artefatos e consumidos por jobs de publicação sem reconstrução a partir de um commit confiável.

Passo 5

A autoridade de publicação alcança a saída não confiável

Os jobs do TestPyPI e npm usavam permissões de publicação OIDC. O advisory descreve que o artefato podia chegar à publicação; não relata comprometimento real de um pacote.

Código-Fonte: Vulnerável vs. Seguro

O GHSL-2026-226 informa que o workflow vulnerável foi removido na PR #10765; isto não afirma que o projeto aplicou a troca de comparador mostrada. A verificação antiga usava -gt, então timestamps inteiros iguais passavam. O controle ilustrativo -ge rejeita igualdade, mas é melhor vincular a aprovação ao commit exato revisado. Separe builds não confiáveis de jobs OIDC, reconstrua a partir do SHA autorizado e valide a proveniência antes da publicação. Nenhum payload de exploração é incluído.

IMPLEMENTAÇÃO VULNERÁVEL
# Workflow marimo-bot removido: comparação em segundos inteiros
if [[ $(date -d "$pushed_at" +%s) -gt $(date -d "$COMMENT_AT" +%s) ]]; then
    exit 1
fi
# O head_sha resultante era usado no checkout e os artefatos
# eram enviados a jobs separados de publicação.
PATCH SEGURO E ROBUSTO
# Controle ilustrativo; segundo o GHSL, o workflow vulnerável
# foi removido, não corrigido no local.
if [[ $(date -d "$pushed_at" +%s) -ge $(date -d "$COMMENT_AT" +%s) ]]; then
    exit 1
fi
# Projeto mais forte: autorizar SHA imutável revisado, reconstruir
# nesse SHA em job confiável e publicar saídas verificadas.

Lista de Verificação de Segurança para Engenharia

Fontes