Pesquisador descontente publica vulnerabilidade do VirtualBox da Oracle

Pesquisador descontente publica vulnerabilidade do VirtualBox da Oracle. Um pesquisador independente que estava insatisfeito com os métodos tradicionais de recompensas de bug resolveu vazar os detalhes de uma exploração no Virtual Box da Oracle sem informar primeiro a Oracle.

Sergey Zelenyuk descobriu uma falha que lhe permitiria escapar do ambiente virtual da máquina guest para alcançar a camada de privilégio Ring 3 usada para executar código da maioria dos programas do usuário com privilégios mínimos.

A vulnerabilidade existe no VirtualBox 5.2.20 e versões anteriores.

O bug pode ser alavancada em máquinas virtuais configuradas com o adaptador de rede Intel PRO / 1000 MT Desktop (82540EM) no modo Network Address Translation (NAT).

O E1000 tem uma vulnerabilidade que permite que um invasor com privilégios de root / administrador em um convidado escape para um host ring3.” Zelenyuk escreveu em um artigo técnico postado em sua conta do GitHub em um artigo técnico. “Então o atacante pode usar técnicas existentes para escalar privilégios para tocar 0 via /dev/vboxdrv.

Zelenyuk disse que gosta do VirtualBox e disponibilizou publicamente o exploit em parte porque os fornecedores levam muito tempo para consertar seus produtos, inconsistências em relação a quais tipos de bugs serão compensados ​​e os preços pouco claros de quanto pesquisadores serão pagos por suas pesquisas.

Eu gosto do VirtualBox e não tem nada a ver com o porquê de publicar uma vulnerabilidade de 0 dia. A razão é meu desacordo com o estado atual de infosec, especialmente de pesquisa de segurança e recompensa de bugs:

1. Aguarde meio ano até que uma vulnerabilidade seja corrigida é considerada boa.

2. No campo de recompensa de bug, estes são considerados bons:

* Aguarde mais de um mês até que uma vulnerabilidade enviada seja verificada e a decisão de comprar ou não comprar seja tomada.

* Altere a decisão na hora. Hoje você descobriu que o programa de recompensas de bugs vai comprar bugs em um software, semana depois você vem com bugs e exploits e recebe “não está interessado”.

* Não tem uma lista precisa de software que uma bug bounty está interessada em comprar. Prático para recompensas de bugs, desajeitado para os pesquisadores.

* Não tem limites inferiores e superiores precisos de preços de vulnerabilidade. Há muitas coisas influenciando um preço, mas os pesquisadores precisam saber o que vale a pena trabalhar e o que não é.

3. Desilusão de grandeza e besteira de marketing: nomear vulnerabilidades e criar sites para elas; fazendo mil conferências em um ano; exagerando a importância do próprio trabalho como pesquisador de segurança; considerando-se “um salvador mundial”. Desça, sua Alteza.

4. Estou exausto dos dois primeiros, portanto, meu movimento é a divulgação completa. Infosec, por favor avance.”


GitHUb Sergey Zelenyuk

A Oracle ainda não disponibilizou correção para a falha.

Exploração

Depois de ativar o conjunto necessário de condições, Zelenyuk é capaz de acionar uma condição de integer overflow  e, mais tarde, um buffer overflow  que poderia ser usado para escapar dos confinamentos do sistema operacional virtual.

Zelenyuk descreveu a exploração como “100% confiável”, acrescentando que “ela funciona sempre ou nunca por causa de binários incompatíveis ou por outros motivos mais sutis que eu não contabilizei“.

Para exploração Zelenyuk usou o kernel Linux (LKM) para carregar em um sistema operacional guest. O caso do Windows exigiria um driver diferente do LKM apenas por um wrapper de inicialização e chamadas de API do kernel.

São necessários privilégios elevados para carregar um driver em ambos os sistemas operacionais. É comum e não é considerado um obstáculo intransponível. Veja o Pwn2Own onde o pesquisador usou cadeias de exploração: um navegador abriu um site mal-intencionado no sistema operacional guest explorado, uma fuga do sandbox do navegador é feita para obter acesso completo ao ring 3, uma vulnerabilidade do sistema operacional é explorada onde há algo que você precisa para atacar um hypervisor do sistema operacional guest. As vulnerabilidades mais poderosas do hypervisor são, com certeza, aquelas que podem ser exploradas a partir do guest ring 3. O VirtualBox também é um código que pode ser acessado sem privilégios de root, e ainda não é auditado.” disse Zelenyuk.

A exploração é 100% confiável. Isso significa que ele funciona sempre ou nunca por causa de binários incompatíveis ou outras razões mais sutis que eu não contei. Ele funciona pelo menos no Ubuntu 16.04 e 18.04 x86_64 guests com configuração padrão.” complementou.

Craig Young, pesquisador de segurança de computadores da Tripwire, disse à SC Media que a vulnerabilidade está na implementação de um adaptador de rede virtual compatível com Intel E1000.

O artigo demonstra como um invasor com permissões para carregar módulos do kernel do Linux em um ambiente guest do Virtual Box pode obter execução de código com pouco privilégio no sistema operacional host, que pode ser elevado para obter acesso administrativo ao host”, disse Young. “Qualquer pessoa que use o Virtual Box para acessar conteúdo não confiável (analistas de malware, por exemplo) deve revisar imediatamente os perfis de suas máquinas e, pelo menos temporariamente, interromper o uso do dispositivo E1000 em favor do adaptador PCNET.”

Young acrescentou que os usuários devem evitar a execução de aplicativos que não sejam confiáveis ​​em qualquer ambiente do Virtual Box com o E1000 habilitado até que o Oracle possa liberar uma correção.

Fonte: SC Media & GitHUb Sergey Zelenyuk

Veja também:

Sobre mindsecblog 1871 Artigos
Blog patrocinado por MindSec Segurança e Tecnologia da Informação Ltda.

1 Trackback / Pingback

  1. CrowdStrike expande presença internacional para atender à crescente demanda do cliente

Deixe sua opinião!