0 
0 Uma vulnerabilidade de execução remota de código (RCE) em um sandbox JavaScript amplamente usado recebeu uma classificação máxima de 10 na escala de risco de vulnerabilidade CVSS; ele permite que os agentes de ameaças executem um escape de sandbox e executem comandos de shell na máquina de hospedagem.
Pesquisadores da empresa de segurança em nuvem Oxeye descobriram a falha perigosa, que eles apelidaram de “Sandbreak” no vm2 , um sandbox JavaScript que tem mais de 16 milhões de downloads mensais, de acordo com seu gerenciador de pacotes NPM.
“O fato de essa vulnerabilidade ter a pontuação máxima de 10 no CVSS e ser extremamente popular significa que seu impacto potencial é generalizado e crítico”, escreveram o arquiteto da Oxeye Yuval Ostrovsky e o pesquisador de segurança Gal Goldshtein em um post publicado em 10 de outubro.
A Oxeye encontrou a falha em 16 de agosto e informou os proprietários do projeto dois dias depois. Em 28 de agosto, o GitHub emitiu o CVE-2022-36067 e atribuiu à vulnerabilidade a classificação de risco mais alta possível.
Os mantenedores do projeto reagiram rapidamente para emitir um patch para o Sandbreak na versão 3.9.11, que deve ser aplicado por qualquer pessoa que use o sandbox devido ao maior risco de vulnerabilidade, disseram os pesquisadores.
Sandboxes: historicamente confiáveis
Como todos os sandboxes, o vm2 oferece um ambiente isolado onde os aplicativos podem executar código confiável, atendendo a propósitos vitais em aplicativos modernos, pois desenvolvedores ou administradores de rede podem usá-los para executar programas ou abrir arquivos sem afetar o aplicativo, sistema ou plataforma em que são executados .
Os desenvolvedores de software costumam usar sandboxes para testar novos códigos de programação, e eles são conhecidos como uma ferramenta importante na pesquisa de segurança cibernética, permitindo que os pesquisadores testem softwares potencialmente maliciosos sem prejudicar outras partes de uma rede ou ambiente de aplicativos.
De fato, o fato de um sandbox ser tão universalmente confiável é o que torna a falha do Sandbreak tão crítica e deve soar um alarme em todos os usuários de sandbox para reforçar suas implementações, disseram os pesquisadores.
“Por sua própria definição, os sandboxes são considerados locais seguros e confiáveis como mecanismos que isolam códigos potencialmente perigosos de nossos aplicativos”, escreveram no post. “Mas o que aconteceria se essa confiança fosse comprometida?”
Análise técnica
Os pesquisadores exploraram exatamente isso em sua investigação do Sandbreak, que descobriram ao analisar lapsos de segurança anteriores divulgados à equipe que mantém vm2.
O bug existe no relator de bugs vm2, o que permitiria que ciberataques abusassem do mecanismo de erro no Node.js. Eles poderiam personalizar a pilha de chamadas de um erro que ocorreu no aplicativo para escapar da sandbox, divulgaram os pesquisadores.
“Personalizar a pilha de chamadas pode conseguir isso implementando o método ‘prepareStacktrace’ no objeto global ‘Error'”, explicaram os pesquisadores no post. “Isso significa que quando ocorre um erro e a propriedade ‘stack’ do objeto de erro lançado é acessada, o Node.js chamará esse método enquanto fornece uma representação de string do erro ao lado de uma matriz de objetos ‘CallSite’ como argumentos. “
Um dos métodos expostos pelos objetos CallSite por causa do problema é “getThis”, que é responsável por retornar o objeto “this” que estava disponível no quadro de pilha relacionado, descobriram os pesquisadores.
Esse comportamento pode levar a escapes do sandbox porque alguns dos objetos “CallSite” “podem retornar objetos criados fora do sandbox ao invocar o método ‘getThis'”, escreveram eles. Se um invasor conseguir obter um objeto “CallSite” criado fora do sandbox, ele poderá acessar os objetos globais do Node e executar comandos arbitrários do sistema a partir daí.
Ignorando a mitigação
Os mantenedores do vm2 estavam cientes de que a substituição de “prepareStackTrace” poderia realmente levar a uma fuga de sandbox. Eles tentaram mitigar o caminho de escape envolvendo o objeto Error e o método “prepareStackTrace” com sua própria implementação, que conseguiu impedir que qualquer pessoa substituísse o método e executasse o escape, disseram eles.
No entanto, os pesquisadores da Oxeye descobriram que poderiam contornar isso, porque o vm2 perdeu métodos específicos relacionados ao tipo embutido JavaScript “WeakMap”, disseram eles. “Isso permitiu que o invasor fornecesse sua própria implementação de ‘prepareStackTrace’, acionasse um erro e escapasse da sandbox”, escreveram os pesquisadores.
Sabendo que a função prepareStackTrace do objeto Error é a função que eles precisavam substituir para escapar da sandbox, os pesquisadores da Oxeye foram ainda mais longe e decidiram tentar substituir o objeto Error global por seu próprio objeto.
Fazer isso implementou a função prepareStackTrace, que permitiu que eles escapassem do sandbox. Alguns passos simples depois e eles tiveram acesso ao processo em execução no momento e puderam executar comandos no sistema que executa o sandbox, disseram eles.
Usando sandboxes com segurança
Embora as sandboxes, por sua própria natureza, sejam destinadas a executar com segurança códigos não confiáveis em um aplicativo ou sistema, as empresas não devem assumir automaticamente que não há riscos, alertaram os pesquisadores.
No entanto, se o uso de um sandbox em um ambiente for inevitável, a Oxeye recomenda reduzir o risco separando a parte lógica e sensível de um aplicativo do microsserviço que executa o código do sandbox.
Isso garantirá que “se um agente de ameaça sair com sucesso da sandbox, a superfície de ataque será limitada ao microsserviço isolado”, escreveram os pesquisadores.
As empresas também devem evitar usar uma sandbox que dependa de uma linguagem de programação dinâmica, como JavaScript, quando possível, disseram eles.
“A natureza dinâmica da linguagem amplia a superfície de ataque para um invasor em potencial, tornando a defesa contra esses ataques muito mais difícil”, observaram os pesquisadores em seu post.
FONTE: DARK READING