Falha crítica no GitLab exige novo patch, mesmo após o de 12/10
A GitLab publicou em 21 de outubro correções para uma falha de nota 10 que permite executar código sem login em servidores self-managed. Quem atualizou em 12/10 não necessariamente está protegido; veja o que checar.
Quem administra um GitLab próprio e marcou o patch de 12 de outubro como concluído deve conferir de novo. Segundo o The Hacker News, a GitLab lançou em 21 de outubro correções para uma falha com nota máxima, CVSS 10.0, que permite a um invasor executar código no servidor sem precisar fazer login.
Por que o patch anterior não resolve
O ponto central da notícia é a diferença entre as duas atualizações. De acordo com a fonte, a de 12 de outubro cobriu apenas as versões 19.2 e posteriores, e as novas versões corrigidas ficam um patch acima dela. Na prática, quem aplicou a atualização de nove dias antes ainda precisa subir de versão. E quem está em uma versão mais antiga não foi alcançado por aquele pacote.
O alcance também é amplo. O Hacker News afirma que a falha atinge todas as versões do software desde a 7.0, lançada em 2014, ou seja, cerca de doze anos de lançamentos. Instalações antigas e esquecidas, comuns em empresas pequenas, entram nesse grupo.
O texto da fonte a que tivemos acesso termina antes de detalhar o identificador da vulnerabilidade, os números exatos das versões corrigidas e possíveis medidas provisórias. Por isso, não listamos esses dados aqui. Eles devem ser confirmados no aviso oficial de segurança da GitLab.
O primeiro passo é saber qual versão roda hoje. Se o servidor foi instalado por um prestador e ninguém na empresa acompanha as atualizações, vale perguntar diretamente a ele. Depois, compare essa versão com as indicadas no aviso oficial de 21 de outubro e agende a atualização com prioridade, não na rotina normal de manutenção.
Uma falha que dispensa autenticação é mais perigosa quando o servidor está acessível pela internet. Quem mantém o GitLab exposto deve avaliar, enquanto não atualiza, se há necessidade real desse acesso ou se é possível restringi-lo por VPN ou lista de IPs. Essa é uma medida geral de prudência, não uma orientação específica da fonte.
Em repositórios costuma ficar código-fonte e, às vezes, chaves e senhas de outros sistemas. Depois de atualizar, faz sentido revisar os registros de acesso do servidor em busca de atividade estranha e, se algo suspeito aparecer, trocar credenciais armazenadas lá. Para empresas que tratam dados pessoais, um incidente nesse ambiente pode ter implicações sob a LGPD, o que justifica registrar o que foi verificado.
Se a empresa não tem equipe para manter um servidor próprio, esta é uma boa ocasião para comparar o custo do self-managed com a versão hospedada pelo fornecedor. A fonte não trata dessa alternativa, então a análise cabe a cada gestor.
Em resumo
O patch de 12 de outubro não encerra o assunto. Confirme a versão, aplique a correção de 21 de outubro e só então considere o risco tratado.
Fontes
Continue lendo
Anatel manda bloquear SMS sem cadastro: o que sua empresa faz
A Anatel determinou que operadoras bloqueiem SMS corporativos de remetentes sem cadastro. Empresas que enviam avisos, cobranças ou códigos por SMS precisam checar se estão no novo diretório antes do fim do prazo de 90 dias.
CibersegurançaVazamento no FGC: o que empresas devem revisar na LGPD
O FGC admitiu acesso indevido a nomes, CPFs e e-mails de investidores. O caso serve de roteiro para pequenas empresas revisarem acessos, fornecedores e o preparo para comunicar um incidente à ANPD.