Uma segunda vulnerabilidade crítica foi divulgada no GitLab em menos de uma semana

Gitlab

Gitlab sofre de um segundo problema de segurança em menos de uma semana

Em menos de uma semana Os desenvolvedores do Gitlab tiveram que começar a trabalhar, Bem, há alguns dias foram lançadas as atualizações corretivas para GitLab Collaborative Development Platform 15.3.1, 15.2.3 e 15.1.5, que resolveram uma vulnerabilidade crítica.

listado em CVE-2022-2884, esta vulnerabilidade pode permitir que um usuário autenticado tenha acesso à API de importação do GitHub executar 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 GitLab Publico 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.

listado em CVE-2022-2992, esta vulnerabilidade permite que um usuário autenticado execute código remotamente 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, atualizações propostas corrigem mais 14 vulnerabilidades, sendo dois marcados como perigosos, dez com gravidade média e dois marcados como não perigosos.

Os seguintes são reconhecidos como perigosos: vulnerabilidade CVE-2022-2865, que permite adicionar seu próprio código JavaScript às páginas exibidas a outros usuários através da manipulação de etiquetas coloridas,

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 das vulnerabilidades que foi solucionada 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 da escala 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 resolvidos:

  • 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

Por fim, se você tiver interesse em saber mais sobre o assunto, pode consultar os detalhes no link a seguir.


Seja o primeiro a comentar

Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.