Um problema relativamente grave sobre o carregamento de DLLs no Windows anda sendo bastante comentado por esses dias. Quase todo software usa várias bibliotecas do sistema, que estão armazenadas em arquivos DLLs. A inicialização delas não é feita com o caminho completo (por exemplo, C:\Windows\dllprocurada.dll) porque não há como saber o camiho físico em todos os PCs (o Windows poderia estar em outra partição, por exemplo). Em vez disso os programas chamam as DLLs do sistema pelo nome do arquivo, e o Windows entrega a primeira que encontrar numa sequencia de diretórios – entre eles, a pasta de sistema, é claro; mas também vale a pasta do executável e a “pasta de trabalho”.
A pasta de trabalho é uma pasta associada a cada processo que varia dependendo das ações do usuário ou do programa; ela é usada quando o usuário tenta salvar ou abrir um arquivo, por exemplo. Ao dar um duplo clique numa foto, a pasta de trabalho do visualizador de fotos configurado para abrir o arquivo será, automaticamente, a pasta onde a foto estava. E normalmente a pasta do programa e a pasta de trabalho é o primeiro local onde o sistema checa se a DLL procurada existe, para depois tentar carregá-la das pastas de sistema. Isso é, de certa forma, bom: os desenvolvedores podem lançar programas que usam algumas DLLs em versões diferentes de outros programas, sem quebrar a compatibilidade com os outros pois cada um guarda consigo as versões das DLLs que usar (especialmente no caso de bibliotecas famosas de terceiros).
Bom, aí entra o problema. Se um programa tenta localizar uma DLL, um dos caminhos de procura é a pasta de trabalho (“working dir”). Uma pessoa maliciosa poderia colocar uma DLL alterada junto com um arquivo, que ele sabe que o programa vai chamar (pelo nome da DLL). Ou seja, uma DLL infectada e uma imagem JPEG, por exemplo. A DLL será chamada pelo programa visualizador quando o usuário der um duplo clique na imagem, aí já viu: o programa rodará de forma alterada e poderá executar o que as funções presentes na DLL pedirem. É um problema um pouco assustador, especialmente se considerar as formas de distribuição. Ao passo que muita gente não abriria um arquivo executável ou .bat, é sabido que a maioria abre arquivos “confiáveis” como imagens, músicas ou até mesmo uma página HTML salva. Se uma DLL maliciosa estiver na mesma pasta…
Como se não bastassem as pastas locais, o problema aparece também ao abrir arquivos a partir de pastas da rede (SMB) e de diretórios WebDav. Vale destacar que não é a simples presença de uma DLL na pasta que fará com que ela seja chamada; é a presença de uma DLL com um nome de DLL que o programa use, então o ataque poderia ter foco em programas comuns e largamente utilizados. No caso o problema é a DLL estar infectada, o arquivo que o usuário clicar pode ser legítimo.
O problema não é novo, mas ainda não foi totalmente solucionado. Modificar o sistema de carregamento por completo quebraria a compatibilidade com muitos softwares atuais, o que é impraticável. A Microsoft comentou o caso e publicou uma medida de correção temporária, que desativa o carregamento de bibliotecas a partir da pasta de trabalho baseando-se em algumas regras definidas pelo administrador.
Em suma a culpa é jogada aos desenvolvedores de programas, que deveriam verificar as pastas e não carregar DLLs da pasta de trabalho, se fosse o caso, limpando a string do caminho da pasta de trabalho antes de carregar as DLLs. Alguns poucos programas realmente necessitam carregar as DLLs a partir da pasta de trabalho, de forma que uma coisa simples se torna complicada – porque é difícil de ser feita, já que envolve provavelmente milhares e milhares de programas.
Pelo visto a falha ainda não foi tão explorada, apesar de ser bastante conhecida e estar presente em muitas versões do Windows. Uma mudança efetiva seria quando cada programador estudasse esse cenário antes de distribuir suas aplicações. E isso não deve ocorrer do dia para a noite, com certeza.
Esta postagem foi modificada pela última vez em 25/08/2010 06:58