Logo após lançar a atualização de segurança 15.1, 15.2 e 15.3, o GitLab revelou a segunda falha crítica em menos de uma semana.
O GitLab é um repositório Git baseado na Web para equipes de desenvolvedores que precisam gerenciar seu código remotamente. Tem aproximadamente 30 milhões de usuários registrados e um milhão de clientes pagantes.
Agora, em menos de uma semana, os desenvolvedores do Gitlab tiveram que começar a trabalhar, pois há poucos dias foram lançadas as atualizações corretivas para a Plataforma de Desenvolvimento Colaborativo GitLab 15.3.1, 15.2.3 e 15.1.5, que resolveu uma vulnerabilidade crítica.
GitLab revelou a segunda falha crítica em menos de uma semana
Sim. O GitLab revelou a segunda falha crítica em menos de uma semana. Catalogada em CVE-2022-2884, essa vulnerabilidade pode permitir que um usuário autenticado com acesso à API de importação do GitHub execute código remotamente em um servidor. Ainda não foram divulgados detalhes operacionais.
A vulnerabilidade foi identificada por um pesquisador de segurança como parte do programa de recompensas de vulnerabilidades do HackerOne.
Como solução alternativa, o administrador foi aconselhado a desativar a importação do recurso GitHub (na interface da Web do GitLab: “Menu” -> “Admin” -> “Configurações” -> “Geral” -> “Visibilidade e controles de acesso » -> «Importar fontes» -> desativar «GitHub»).
Depois disso e em menos de uma semana o GitLab publicou a próxima série de atualizações corretivas para sua plataforma de desenvolvimento colaborativo: 15.3.2, 15.2.4 e 15.1.6, que corrige a segunda vulnerabilidade crítica.
Catalogada sob CVE-2022-2992, esta vulnerabilidade permite que um usuário autenticado execute remotamente código em um servidor.
Assim como a vulnerabilidade CVE-2022-2884 que foi corrigida há uma semana, há um novo problema de API para importar dados do serviço GitHub.
A vulnerabilidade se manifesta, entre outras coisas, nas versões 15.3.1, 15.2.3 e 15.1.5, nas quais a primeira vulnerabilidade no código de importação do GitHub foi corrigida.
Ainda não foram divulgados detalhes operacionais. A vulnerabilidade foi enviada ao GitLab como parte do programa de recompensas de vulnerabilidades do HackerOne, mas, diferentemente da edição anterior, foi identificada por outro colaborador.
Como solução alternativa, recomenda-se que o administrador desative a importação do recurso GitHub (na interface web do GitLab: “Menu” -> “Admin” -> “Configurações” -> “Geral” -> “Visibilidade e controles de acesso » -> «Importar fontes» -> desativar «GitHub»).
Além disso, as atualizações propostas corrigem 14 vulnerabilidades adicionais, duas das quais são marcadas como perigosas, dez das quais têm um nível de gravidade médio e duas das quais são marcadas como não perigosas.
Os seguintes são conhecidos por serem perigosos: a vulnerabilidade CVE-2022-2865, que permite adicionar seu próprio código JavaScript a páginas exibidas a outros usuários por meio da manipulação de tags de cores.
“Foi possível explorar uma vulnerabilidade configurando o recurso de cor do rótulo que poderia levar ao XSS armazenado que permitia que invasores executassem ações arbitrárias em nome das vítimas no lado do cliente.”
Outra vulnerabilidade que foi corrigida com a nova série de correções é a CVE-2022-2527, que possibilita a substituição de seu conteúdo pelo campo de descrição na linha do tempo de escalação de incidentes).
As vulnerabilidades de gravidade média estão principalmente relacionadas ao potencial de negação de serviço.
“A falta de validação de comprimento nas descrições de snippets no GitLab CE/EE afetando todas as versões anteriores a 15.1.6, todas as versões de 15.2 anteriores a 15.2.4, todas as versões de 15.3 anteriores a 15.3.2 permite que um invasor autenticado crie um snippet mal-intencionado grande que, quando solicitado com ou sem autenticação, causa carga excessiva no servidor, potencialmente levando a uma negação de serviço.”
Das outras vulnerabilidades que foram corrigidas:
- O registro de pacotes não respeita totalmente a lista de permissões de IP do grupo, o GitLab não estava autenticando corretamente em algum Registro de Pacotes quando as restrições de endereço IP foram configuradas, permitindo que um invasor que já possuía um token de implantação válido faça uso indevido dele de qualquer local.
- Abusar das chamadas do Gitaly.GetTreeEntries leva a uma negação de serviço, permitindo que um usuário autenticado e autorizado esgote os recursos do servidor importando um projeto malicioso.
- Possíveis solicitações HTTP arbitrárias no .ipynb Notebook com tags de formulário maliciosos, o que permite que um invasor emita solicitações HTTP arbitrárias.
- A negação de serviço de expressão regular por meio de entrada criada permitiu que um invasor acionasse alto uso da CPU por meio de uma entrada criada adicionada ao campo Confirmar mensagem.
- Divulgação de informações por meio de referências GFM arbitrárias representadas em eventos de cronograma de incidentes
- Ler o conteúdo do repositório por meio da função LivePreview: era possível para um usuário não autorizado ler o conteúdo do repositório se um membro do projeto usasse um link criado.
- Negação de serviço via API ao criar uma ramificação: o manuseio inadequado de dados na criação da ramificação pode ter sido usado para acionar o alto uso da CPU.
- Negação de serviço por meio da visualização do problema
[postlist tags=”imagens” requesttype=”1″ number=”4″]