Uma equipe de pesquisadores do Google chamada Project Zero (GPZ), divulgou uma vulnerabilidade de alta gravidade no recurso de execução de ações do GitHub, que pode permitir invasores executarem códigos remotamente em sistemas afetados.
O bug foi encontrado por Felix Wilhelm do Project Zero, em 21 de julho. De acordo com Wilhelm, os comandos de fluxo de trabalho do Actions são "altamente vulneráveis a ataques de injeção".
Esses comandos de fluxo de trabalho atuam como um canal de comunicação entre o executor de ação e a ação executada.
"O grande problema com esse recurso é que ele é altamente vulnerável a ataques de injeção. Como o processo de execução analisa cada linha impressa em STDOUT em busca de comandos de fluxo de trabalho, cada ação do Github que imprime conteúdo não confiável como parte de sua execução é vulnerável. Na maioria dos casos, a capacidade de definir variáveis de ambiente arbitrárias resulta na execução remota de código assim que outro fluxo de trabalho é executado. Passei algum tempo examinando repositórios Github populares e quase todos os projetos com ações Github um tanto complexas são vulneráveis a essa classe de bug", explicou Wilhelm em um relatório do Project Zero.
Após a descoberta do bug, a equipe de pesquisa do Google entrou em contato com o GitHub com informações sobre a vulnerabilidade em sua plataforma. Dando um prazo de 90 dias, de acordo com a política de divulgação revisada (que expirou em 18 de outubro) para corrigir o problema antes que os detalhes do bug seja divulgado publicamente.
A política de divulgação revisada do GPZ aguarda pelo menos 90 dias antes de revelar publicamente os detalhes de um bug de segurança, mesmo que o bug seja corrigido antes desse prazo.
Além disso, os fornecedores podem solicitar um período de carência adicional de 14 dias para o Google se acreditarem que não serão capazes de corrigir a vulnerabilidade relatada em 90 dias.
Com o fim do prazo se aproximando, o GitHub emitiu um comunicado de segurança em 1 de outubro e suspendeu os comandos vulneráveis, set-env e add-path.
Uma descrição do problema também foi postada constatando que o que o GPZ havia encontrado era, na verdade, uma "vulnerabilidade de segurança moderada" e atribuiu ao bug o identificador de rastreamento CVE-2020-15228. O comunicado solicita os usuários a atualizar seus fluxos de trabalho.
"Uma vulnerabilidade de segurança moderada foi identificada no GitHub Actions runner que pode permitir a variável de ambiente e injeção de caminho em fluxos de trabalho que registram dados não confiáveis no STDOUT", disse o comunicado do GitHub.
"Isso pode resultar na introdução ou modificação de variáveis de ambiente sem a intenção do autor do fluxo de trabalho", acrescentou.
"Para resolver esse problema, introduzimos um novo conjunto de arquivos para gerenciar atualizações de ambiente e caminho em fluxos de trabalho. Se você estiver usando corredores auto-hospedados, certifique-se de que eles estejam atualizados para a versão 2.273.1 ou superior", concluiu.
Wilhelm disse que os comandos de fluxo de trabalho no GitHub Action são difíceis de corrigir. "A forma como os comandos de fluxo de trabalho são implementados é fundamentalmente insegura." A solução do GitHub é remover gradualmente os comandos arriscados de forma permanente.
Em 12 de outubro, o GPZ contatou o GitHub e ofereceu proativamente um período de carência de 14 dias para desabilitar totalmente os comandos. A plataforma do desenvolvedor aceitou a oferta sabendo que o bug seria divulgado publicamente em 2 de novembro.
Porém, apenas um dia antes do fim do período de tolerância, o GitHub deu sua resposta oficial e solicitou uma extensão adicional de 48 horas para notificar os clientes sobre uma correção em uma data futura.
"O GitHub responde e menciona que não desativará os comandos vulneráveis em 2020-11-02. Eles solicitam 48 horas adicionais, não para corrigir o problema, mas para notificar os clientes e determinar uma 'data difícil' em algum momento no futuro", escreveu Wilhelm.
No entanto, o GPZ foi em frente e divulgou o bug que relatou porque, de acordo com sua política, ele não pode oferecer uma extensão além dos 104 dias (90 dias 14 dias de prorrogação).
"Os períodos de carência não serão concedidos para vulnerabilidades que devem levar mais de 104 dias para serem corrigidas", afirma o Google Project Zero em sua política de divulgação de 2020.
