Windows, instaladores e DLLs

Vulnerabilidade conhecida há mais de 15 anos encontra-se presente em grande parte dos programas de instalação

Em 14 de novembro de 2000, foi publicado um boletim de segurança alertando para a existência de um problema de segurança presente nos aplicativos da suíte Microsoft Office 2000.

O boletim é uma das primeiras referências que podem ser encontradas sobre a vulnerabilidade listada no dicionário Common Weakness Enumeration (CWE) como Uncontrolled Search Path Element, que ocorre quando um programa solicita um recurso que pode ser carregado a partir de um diretório cujo conteúdo é controlável ou influenciável por um atacante.

Apesar da possibilidade de existir em aplicativos desenvolvidos para diversos sistemas operacionais, os casos mais comuns da falha envolvem o Windows e arquivos DLL — razão pela qual ela tornou-se conhecida também como DLL hijacking ou DLL preloading.

A sigla DLL significa dynamic link library, nome dado às bibliotecas dinâmicas do Windows.

Os sistemas operacionais mais populares da atualidade suportam bibliotecas dinâmicas: no OS X, chamam-se dynamic libraries (dylib), e em distribuições Linux, shared objects (so). Por possibilitarem que programas compartilhem código, elas promovem a economia de recursos como o espaço de armazenamento disponível.

Mas a tendência do Windows e de suas DLLs a protagonizarem os boletins de segurança sobre a vulnerabilidade não é meramente fruto do acaso. Em determinadas situações, o sistema operacional da Microsoft realiza uma busca em uma sequência pré-determinada de diretórios para localizar recursos, incluindo bibliotecas dinâmicas, quando estes são solicitados pelos programas. Tal processo, pela maneira como foi projetado, favorece ocorrências da falha.

Os recentes esforços do pesquisador de segurança Stefan Kanthak destacam um método de exploração que, apesar de ser discutido pelo menos desde 2012, ainda pode ser aplicado com sucesso. A técnica, conhecida como carpet bombing ou directory poisoning, é altamente focada em programas de instalação vulneráveis, sendo baseada nos seguintes fatos:

1. Grande parte dos utilizadores salvam os instaladores que transferem por meio da Internet na pasta de downloads, não movendo-os para outro diretório antes de iniciá-los;
2. Muitas vezes, tais instaladores são, também, programas, e estes podem solicitar ao sistema o carregamento de DLLs;
3. Na ordem de busca padrão utilizada pelo Windows para localizar DLLs, o diretório onde encontra-se o programa que a solicitou é o primeiro a ser pesquisado.

Assim, se um instalador vulnerável na pasta de downloads é executado e dá início ao processo de busca padrão por uma DLL, o Windows tentará localizá-la nesta mesma pasta. Em situações normais, o arquivo não existiria, e a pesquisa continuaria nos diretórios do sistema, conforme ilustrado a seguir.

Porém, se um atacante, por meio de engenharia social simples ou de outros meios mais elaborados, insere uma DLL no diretório de downloads, as chances de que sua remoção pelo utilizador não ocorreria e ela acabaria tendo seu código executado na próxima vez que um instalador vulnerável fosse iniciado seriam bastante altas.

Há uma enorme quantidade de softwares afetados. Alguns exemplos são o instalador do navegador Chrome — a vulnerabilidade foi reportada por Kanthak ao Google, que decidiu não a corrigir, pois alega que a falha só poderia ser explorada por alguém com “total controle” sobre o computador, apesar de todo o material disponível indicar o contrário — e até os de ferramentas de empresas da área de segurança, como a Rapid7 e a Kaspersky Labs — que tomaram as medidas adequadas.

Para que possam proteger seus programas de ataques deste tipo, os desenvolvedores precisam compreender o funcionamento das DLLs, do processo de busca e como utilizar estas bibliotecas de forma segura. A leitura do tópico de Kanthak na lista de e-mail Full Disclosure a respeito do assunto e do documento intitulado “Dynamic-Link Library Security”, publicado pela Microsoft, podem ser boas formas de começar.

Além disso, é altamente recomendável o estudo de como a vulnerabilidade pode ocorrer com outros tipos de recursos que não DLLs, e até mesmo em outros sistemas operacionais. Alguns exemplos são o caso do Safari para Windows e o do Ghostscript em distribuições Linux, ambos documentados em 2010.