🔥 Fique por dentro das novidades mais quentes do momento! 🔥
Sua opinião é importante: leia e participe!
Apoie esse projeto de divulgacao de noticias! Clique aqui
Pesquisadores de segurança em profundidade publicaram pela primeira vez um código de exploração funcional em 24 de julho para uma falha do GitLab que o GitLab corrigiu seis semanas antes, em 10 de junho. Ele executa comandos como git em qualquer servidor 18.11.3 autogerenciado que não tenha recebido a atualização.
Qualquer usuário autenticado que possa enviar para um projeto pode executá-lo. O invasor confirma um notebook Jupyter criado e abre seu diff de commit, que vaza um ponteiro de heap. Chega disso e uma investigação automatizada pode localizar as bibliotecas na memória. Mais dois notebooks disparam a carga útil. Sem direitos de administrador, sem acesso de CI ou executor, sem interação com a vítima, sem acesso ao projeto de outra pessoa.
O GitLab não registrou a correção como uma correção de segurança. Uma análise do The Hacker News encontrou o problema do Oj 3.17.3 listado nas correções de bugs no lançamento do patch de 10 de junho, não na tabela de correções de segurança. Não há CVE, pontuação CVSS e nenhuma menção à cadeia de diferenças de notebook. Os operadores que fizeram a triagem dessa liberação em relação à tabela de segurança não tinham motivos para tratá-la como urgente.
Dois bugs de corrupção de memória no Oj, um analisador Ruby JSON implementado em grande parte em C nativo, fazem a cadeia funcionar. deepfirst diz que seu sistema os sinalizou de forma autônoma e os pesquisadores os acorrentaram manualmente.
O renderizador de notebook do GitLab, uma gema na árvore chamada ipynbdiff, passa JSON .ipynb controlado pelo repositório para Oj::Parser.usual.parse dentro de um trabalhador Puma de longa duração, para que os bytes controlados pelo invasor alcancem a memória C gerenciada manualmente de Oj dentro do processo do aplicativo.
Um bug grava uma pilha de aninhamento fixa de 1.024 bytes até controlar o retorno de chamada inicial do analisador. O outro trunca uma chave de objeto de 65.565 bytes para 29 em um campo assinado de 16 bits e retorna um ponteiro de heap ativo, que o GitLab renderiza no diff. O vazamento localiza libc e a gravação aponta o retorno de chamada para system().
ComponentAffectedFirst corrigido
GitLab CE/EE15.2.0 a 18.10.718.10.8
GitLab CE/EE18.11.0 a 18.11.418.11.5
GitLab CE/EE19.0.0 a 19.0.119.0.2
Jo gem3.13.0 a 3.17.13.17.3
Todos os níveis são afetados, CE e EE, Gratuito até Ultimate. Ruby em si não é. Oj 3.17.2 trouxe outras correções da mesma revisão, mas não essas duas.
Atualize para 18.10.8, 18.11.5 ou 19.0.2. Nem o GitLab nem o deepfirst oferecem uma solução alternativa para quem não consegue.
A armadilha é Helm e Operador: verifique a versão do GitLab dentro da imagem do Webservice executando o Puma, não o gráfico ou a versão do Operador. Qualquer coisa entre 15.2 e 18.9 não tem backport, porque essas linhas ficam fora dos trens de patch mantidos pela segurança do GitLab, então essas instalações precisam migrar para uma versão com suporte.
Os comandos são executados como git, a conta por trás do Puma. Até onde isso vai depende de como a instalação é isolada. Ao alcance: código-fonte, segredos do Rails, credenciais de serviço, dados de CI/CD e serviços internos com os quais o aplicativo pode se comunicar.
A exploração pública foi criada para GitLab 18.11.3 em x86-64. As compensações do gadget, o estado do registro e o comportamento do jemalloc vieram todos dessa imagem, e uma base de biblioteca recuperada é mantida apenas até que o mestre do Puma seja reiniciado, portanto, isso não ocorre em um alvo arbitrário.
Os bugs do Oj são gerais; portar o exploit é um trabalho real. O deepfirst mediu de cinco a dez minutos para a pesquisa de memória em uma instalação nova de dois trabalhadores e projetou de uma a duas horas em instalações de execução mais longa. Sua redação contém a cadeia completa.
O deepfirst relatou os bugs do Oj em 21 de maio, o mantenedor fundiu as correções em 27 de maio e o Oj 3.17.3 foi enviado em 4 de junho. A cadeia GitLab foi para o GitLab em 5 de junho, foi confirmada em 8 de junho e corrigida em 10 de junho. Sua revisão mais ampla do OJ produziu mais nove comunicados CVE, nenhum deles nesta cadeia.
O Hacker News perguntou ao GitLab por que a correção não foi classificada como um problema de segurança e se um CVE será atribuído, e perguntou profundamente sobre a portabilidade do exploit. As respostas estão pendentes.
Qualquer usuário autenticado que possa enviar para um projeto pode executá-lo. O invasor confirma um notebook Jupyter criado e abre seu diff de commit, que vaza um ponteiro de heap. Chega disso e uma investigação automatizada pode localizar as bibliotecas na memória. Mais dois notebooks disparam a carga útil. Sem direitos de administrador, sem acesso de CI ou executor, sem interação com a vítima, sem acesso ao projeto de outra pessoa.
O GitLab não registrou a correção como uma correção de segurança. Uma análise do The Hacker News encontrou o problema do Oj 3.17.3 listado nas correções de bugs no lançamento do patch de 10 de junho, não na tabela de correções de segurança. Não há CVE, pontuação CVSS e nenhuma menção à cadeia de diferenças de notebook. Os operadores que fizeram a triagem dessa liberação em relação à tabela de segurança não tinham motivos para tratá-la como urgente.
Dois bugs de corrupção de memória no Oj, um analisador Ruby JSON implementado em grande parte em C nativo, fazem a cadeia funcionar. deepfirst diz que seu sistema os sinalizou de forma autônoma e os pesquisadores os acorrentaram manualmente.
O renderizador de notebook do GitLab, uma gema na árvore chamada ipynbdiff, passa JSON .ipynb controlado pelo repositório para Oj::Parser.usual.parse dentro de um trabalhador Puma de longa duração, para que os bytes controlados pelo invasor alcancem a memória C gerenciada manualmente de Oj dentro do processo do aplicativo.
Um bug grava uma pilha de aninhamento fixa de 1.024 bytes até controlar o retorno de chamada inicial do analisador. O outro trunca uma chave de objeto de 65.565 bytes para 29 em um campo assinado de 16 bits e retorna um ponteiro de heap ativo, que o GitLab renderiza no diff. O vazamento localiza libc e a gravação aponta o retorno de chamada para system().
ComponentAffectedFirst corrigido
GitLab CE/EE15.2.0 a 18.10.718.10.8
GitLab CE/EE18.11.0 a 18.11.418.11.5
GitLab CE/EE19.0.0 a 19.0.119.0.2
Jo gem3.13.0 a 3.17.13.17.3
Todos os níveis são afetados, CE e EE, Gratuito até Ultimate. Ruby em si não é. Oj 3.17.2 trouxe outras correções da mesma revisão, mas não essas duas.
Atualize para 18.10.8, 18.11.5 ou 19.0.2. Nem o GitLab nem o deepfirst oferecem uma solução alternativa para quem não consegue.
A armadilha é Helm e Operador: verifique a versão do GitLab dentro da imagem do Webservice executando o Puma, não o gráfico ou a versão do Operador. Qualquer coisa entre 15.2 e 18.9 não tem backport, porque essas linhas ficam fora dos trens de patch mantidos pela segurança do GitLab, então essas instalações precisam migrar para uma versão com suporte.
Os comandos são executados como git, a conta por trás do Puma. Até onde isso vai depende de como a instalação é isolada. Ao alcance: código-fonte, segredos do Rails, credenciais de serviço, dados de CI/CD e serviços internos com os quais o aplicativo pode se comunicar.
A exploração pública foi criada para GitLab 18.11.3 em x86-64. As compensações do gadget, o estado do registro e o comportamento do jemalloc vieram todos dessa imagem, e uma base de biblioteca recuperada é mantida apenas até que o mestre do Puma seja reiniciado, portanto, isso não ocorre em um alvo arbitrário.
Os bugs do Oj são gerais; portar o exploit é um trabalho real. O deepfirst mediu de cinco a dez minutos para a pesquisa de memória em uma instalação nova de dois trabalhadores e projetou de uma a duas horas em instalações de execução mais longa. Sua redação contém a cadeia completa.
O deepfirst relatou os bugs do Oj em 21 de maio, o mantenedor fundiu as correções em 27 de maio e o Oj 3.17.3 foi enviado em 4 de junho. A cadeia GitLab foi para o GitLab em 5 de junho, foi confirmada em 8 de junho e corrigida em 10 de junho. Sua revisão mais ampla do OJ produziu mais nove comunicados CVE, nenhum deles nesta cadeia.
O Hacker News perguntou ao GitLab por que a correção não foi classificada como um problema de segurança e se um CVE será atribuído, e perguntou profundamente sobre a portabilidade do exploit. As respostas estão pendentes.
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #pesquisador #publica #gitlab #rce #poc #permitindo #que #usuários #autenticados #executem #comandos #como #git
🚀 Mais conteúdos incríveis estão por vir, fique atento!
Postar um comentário