Risco de segurança no método de carregamento de DLLs do Windows


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.

Fonte: Guia do Hardware

2 Responses to Risco de segurança no método de carregamento de DLLs do Windows

  1. Pingback: Microsoft atualiza informações sobre o problema do carregamento das DLLs « BloGNU

Conte-nos o que achou...

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: