Ultrapassando a Assinatura de Código do Kernel (II)

O principal problema da assinatura digital do código do kernel não são ferramentas como o Atsiv, que podem ser facilmente identificadas e removidas pelos softwares anti-malware. O problema real são as vulnerabilidades encontradas eventualmente em drivers legítimos: um estouro de buffer no seu driver de vídeo, por exemplo, que possa ser explorado para carregar código malicioso dentro do kernel. Um ataque de fuzzing contra os drivers tipicamente instalados em um Vista 64-bits provavelmente vai mostrar várias destas vulnerabilidades.

A raiz do problema está no próprio modelo de drivers utilizado pelo Windows Vista (e por todos os outros principais sistemas operacionais no mercado). O Vista não faz nenhum tipo de isolamento entre os drivers e o restante do código do kernel, excetuando a proteção feita a algumas estruturas pelo Patchguard, e ao carregar um driver sem perceber você está confiando a ele toda a segurança do seu kernel. Em um sistema Vista com 15 drivers carregados de fabricantes diferentes, a proteção do seu kernel depende da segurança destes 15 drivers escritos por até 15 fabricantes diferentes. E isso certamente não é uma boa coisa.

Infelizmente existe pouco o que se pode fazer a curto prazo para remediar isso. Em um post anterior eu listei algumas das ações que a Microsoft está fazendo:

¦ A Microsoft incluiu a ferramenta de análise de código estático PreFAST como parte do kit de desenvolvimento de drivers, e é um dos requisitos para homologação do driver dentro da WHQL

¦ A Microsoft também está fazendo treinamentos de segurança específicos para desenvolvedores de drivers, como este mostrado no blog do Michael Howard.

¦ O Windows Update detecta e atualiza drivers do sistema com novas versões.

No Windows Vista a Microsoft também deu o primeiro passo em termos de arquitetura para diminuir esta vulnerabilidade, movendo para o modo usuário (i.e. para fora do kernel) os drivers para um conjunto grande de dispositivos, como dispositivos de armazenamento USB, câmeras e tocadores de MP3. Para o futuro a tendência é obter um isolamento cada vez maior do kernel e reduzir a confiança que é depositada nos drivers, e eventualmente chegarmos em um cenário onde isso será irrelevante, porque o hypervisor (e não mais o kernel) será o código de maior confiança rodando no sistema.