Carregamento seguro de bibliotecas para evitar ataques de pré-carregamento da DLL

Ataques baseados em LoadLibrary

Quando uma aplicação carrega dinamicamente um DLL sem especificar um caminho totalmente qualificado, o Windows tenta localizar este DLL procurando linearmente através de um conjunto bem definido de diretórios, conhecidos como DLL Search Order. Se o Windows localizar o DLL dentro da Ordem de Pesquisa DLL, carregará esse DLL. No entanto, se o Windows não encontrar o DLL em nenhum dos diretórios da Ordem de Pesquisa DLL, retornará uma falha na operação de carga DLL. Segue-se a Ordem de Pesquisa DLL para as funções LoadLibrarye LoadLibraryEx,que são utilizadas para carregar dinamicamente DLLs:

1. O diretório a partir do qual a aplicação carregada

2. O diretório do sistema

3. O diretório de sistema de 16 bits

4. O diretório do Windows

5. O atual diretório de trabalho (CWD)

6. Os diretórios que estão listados na variável ambiente PATH

Considere o seguinte cenário:

• Uma aplicação carrega um DLL sem especificar um caminho totalmente qualificado que espera encontrar no CWD da aplicação.

• O pedido está totalmente preparado para lidar com o caso quando não encontrar o DLL.

• O intruso conhece esta informação sobre a aplicação e controla o CWD.

• O agressor copia a sua própria versão especialmente trabalhada do DLL no CWD. Isto pressupõe que o agressor tem permissão para fazer isto.

• O Windows procura através dos diretórios na Ordem de Pesquisa DLL e encontra o DLL no CWD da aplicação.

Neste cenário, o DLL especialmente trabalhado funciona dentro da aplicação e obtém os privilégios do utilizador atual.

Recomendação

Para prevenir este ataque, as aplicações podem remover o diretório de trabalho atual (CWD) do caminho de pesquisa DLL, chamando a API SetDllDirectory usando uma corda vazia (""). Se uma aplicação depender do carregamento de um DLL do diretório atual, obtenha o diretório de trabalho atual e use-o para passar num caminho totalmente qualificado de LoadLibrary.



Também sabemos que alguns desenvolvedores usam LoadLibrary para validar se um DLL específico está presente para determinar qual a versão do Windows que está a ser executada pelo utilizador. Deve saber que isto pode tornar a aplicação vulnerável. Se a biblioteca afetada não existir na versão do Windows em que a aplicação é executada, um intruso pode introduzir uma biblioteca com o mesmo nome no CWD. Recomendamos vivamente contra a utilização desta técnica. Em vez disso, utilize as técnicas recomendadas que são descritas no artigo da MSDN, "Obter a Versão do Sistema".

Uma aplicação que carregue plugins de terceiros e que não possa forçar os plugins a utilizar um caminho qualificado para as suas chamadas LoadLibrary deve ligar para SetDllDirect("") para remover o CWD e, em seguida, ligar para SetDllDirectory ("plugin install location") para adicionar o diretório de instalação plugin à via de pesquisa DLL.

Ataques baseados em SearchPath

Um ataque semelhante existe quando uma aplicação utiliza a API SearchPath para localizar um DLL e carregar dinamicamente o caminho que é devolvido pelo SearchPath. Segue-se a ordem de pesquisa predefinido para a API SearchPath:

• O diretório a partir do qual a aplicação carregada

• O atual diretório de trabalho (CWD)

• O diretório do sistema

• O diretório de sistema de 16 bits

• O diretório do Windows

• Os diretórios que estão listados na variável ambiente PATH

Não recomendamos este padrão porque não é seguro. Não recomendamos a função SearchPath como um método de localização de um ficheiro .dll se a utilização pretendida da saída estiver numa chamada para a função LoadLibrary. Isto pode resultar na localização do ficheiro .dll errado porque a ordem de pesquisa da função SearchPath difere da ordem de pesquisa utilizada pela função LoadLibrary. Se tiver de localizar e carregar um ficheiro .dll, utilize a função LoadLibrary.

ShellExecute e CreateProcess

Variações destes problemas também podem existir quando os desenvolvedores chamam funções semelhantes, tais como ShellExecutee CreateProcesspara carregar executáveis externos. Recomendamos que os desenvolvedores tenham cuidado quando estão a carregar binários e especifiquem o caminho totalmente qualificado. Isto deve representar menos complexidade quando se carrega um binário em vez de uma biblioteca.

Orientação sobre a identificação de cargas não-seceis da biblioteca

No código fonte, são exemplos de cargas de biblioteca nãoseceis:

• No seguinte exemplo de código, a aplicação procura "schannel.dll" utilizando o caminho de pesquisa menos seguro. Se um intruso puder colocar schannel.dll em CWD, será carregado mesmo antes da aplicação procurar nos diretórios do Windows para a biblioteca apropriada.

  DWORD retval = SearchPath(NULL, "schannel", ".dll", err, result, NULL); 
  HMODULE handle = LoadLibrary(result);

• No seguinte exemplo de código, a aplicação tenta carregar a biblioteca a partir das várias aplicações e locais do sistema operativo descritos no início deste documento para a chamada LoadLibrary(). Se houver algum risco de que o ficheiro não esteja presente, o pedido pode tentar carregar o ficheiro do diretório de trabalho atual. Este cenário é ligeiramente menos perigoso do que o exemplo anterior. No entanto, ainda expõe o utilizador da aplicação ao risco se o ambiente não for completamente previsível.

  HMODULE handle = LoadLibrary("schannel.dll");

Seguem-se exemplos de cargas de bibliotecas melhores e mais seguras:

• No seguinte exemplo de código, a biblioteca é carregada diretamente utilizando um caminho totalmente qualificado. Não existe qualquer risco de o intruso introduzir código malicioso a menos que ele já tenha permissões de escrita para o diretório alvo da aplicação.
  
  

  HMODULE handle = LoadLibrary("c:\\windows\\system32\\schannel.dll");

  
  
  Nota Para obter informações sobre como determinar o diretório do sistema, consulte os seguintes recursos:
  
  GetSystemDirectory

  http://msdn.microsoft.com/en-us/library/ms724373%28VS.85%29.aspxSHGetKnownFolderPath

  http://msdn.microsoft.com/en-us/library/bb762188%28v=VS.85%29.aspx

• No seguinte exemplo de código, o diretório de trabalho atual é removido do caminho de pesquisa antes de chamar LoadLibrary. Isto reduz significativamente o risco, uma vez que o intruso teria de controlar o diretório de aplicações, o diretório do Windows ou quaisquer diretórios especificados no caminho do utilizador para utilizar um ataque de pré-carregamento DLL.

  SetDllDirectory ("");
  HMODULE handle = LoadLibrary("schannel.dll");

• Em todos os sistemas que tenham instalado a atualização de segurança 963027 (descrito em MS09-014),o seguinte código iria mover permanentemente a CWD para o último local da ordem de pesquisa. Quaisquer chamadas posteriores para a função SetSearchPathMode a partir de dentro desse processo que tentem alterar o modo de pesquisa falharão.

  SetDllDirectory ("");
  HMODULE handle = LoadLibrary("schannel.dll");
  

• No seguinte exemplo de código, o diretório de trabalho atual é removido do caminho de pesquisa antes de chamar LoadLibrary. Isto reduz significativamente o risco, uma vez que o intruso teria de controlar o diretório de aplicações, o diretório do windows ou quaisquer diretórios especificados no caminho do utilizador para utilizar um ataque de pré-carregamento DLL.

  SetSearchPathMode (BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE | BASE_SEARCH_PATH_PERMANENT );
  HMODULE handle = LoadLibrary("schannel.dll");