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

Ataques baseados em LoadLibrary

Quando um aplicativo carrega dinamicamente uma DLL sem especificar um caminho totalmente qualificado, o Windows tenta localizar essa DLL pesquisando linearmente por meio de um conjunto bem definido de diretórios, conhecido como Ordem de Pesquisa de DLL. Se Windows localizar a DLL dentro da Ordem de Pesquisa DLL, ela carregará essa DLL. No entanto, Windows não encontrar a DLL em nenhum dos diretórios na Ordem de Pesquisa DLL, ele retornará uma falha na operação de carga DLL. Veja a seguir a Ordem de Pesquisa de DLL para as funções LoadLibrarye LoadLibraryEx,que são usadas para carregar dinamicamente DLLs:

1. O diretório do qual o aplicativo foi carregado

2. O diretório do sistema

3. O diretório do sistema de 16 bits

4. O diretório do Windows

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

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

Considere o seguinte cenário:

• Um aplicativo carrega uma DLL sem especificar um caminho totalmente qualificado que ele espera encontrar no CWD do aplicativo.

• O aplicativo está totalmente preparado para lidar com o caso quando não encontra a DLL.

• O invasor conhece essas informações sobre o aplicativo e controla o CWD.

• O invasor copia sua própria versão especialmente elaborada da DLL na CWD. Isso supõe que o invasor tenha permissão para fazer isso.

• Windows pesquisa nos diretórios na Ordem de Pesquisa DLL e localiza a DLL no CWD do aplicativo.

Nesse cenário, a DLL especialmente trabalhada é executado dentro do aplicativo e obtém os privilégios do usuário atual.

Recomendação Para evitar esse ataque, os aplicativos podem remover o diretório de trabalho atual (CWD) do caminho de pesquisa DLL chamando
a API SetDllDirectory usando uma cadeia de caracteres
vazia (""). Se um aplicativo depender do carregamento de uma DLL do diretório atual, obtenha o diretório de trabalho atual e use-o para passar em um caminho totalmente qualificado de LoadLibrary.



Também estamos cientes de que alguns desenvolvedores usam LoadLibrary para validar se uma DLL específica está presente para determinar qual versão do Windows está sendo executado pelo usuário. Você deve estar ciente de que isso pode tornar o aplicativo vulnerável. Se a biblioteca afetada realmente não existir na versão Windows em que o aplicativo é executado, um invasor poderia introduzir uma biblioteca com o mesmo nome no CWD. É recomendável não usar essa técnica. Em vez disso, use as técnicas recomendadas descritas no artigo do MSDN, "Getting the System Version".

Um aplicativo que carrega plug-ins de terceiros e que não pode forçar os plug-ins a usar um caminho qualificado para suas chamadas LoadLibrary deve chamar SetDllDirectory("") para remover CWD e chamar SetDllDirectory("plug install location") para adicionar o diretório de instalação do plug-in ao caminho de pesquisa DLL.

Ataques baseados em SearchPath

Um ataque semelhante existe quando um aplicativo usa a API SearchPath para localizar uma DLL e carregar dinamicamente o caminho retornado pelo SearchPath. A seguir está a ordem de pesquisa padrão para a API searchPath:

• O diretório do qual o aplicativo foi carregado

• O diretório de trabalho atual (CWD)

• O diretório do sistema

• O diretório do sistema de 16 bits

• O diretório do Windows

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

Não recomendamos esse padrão porque ele não é seguro. Não recomendamos a função SearchPath como um método de localizar um arquivo .dll se o uso pretendido da saída estiver em uma chamada para a função LoadLibrary. Isso pode resultar na localização do arquivo .dll errado porque a ordem de pesquisa da função SearchPath difere da ordem de pesquisa usada pela função LoadLibrary. Se você tiver que localizar e carregar um arquivo .dll, use a função LoadLibrary.

ShellExecute e CreateProcess

Variações desses problemas também podem existir quando os desenvolvedores chamam funções semelhantes, como ShellExecutee CreateProcess,para carregar executáveis externos. Recomendamos que os desenvolvedores tenham cuidado ao carregar binários e especifiquem o caminho totalmente qualificado. Isso deve representar menos complexidade quando você carrega um binário em vez de uma biblioteca.

Diretrizes sobre a identificação de cargas de biblioteca não-secretura

No código-fonte, os exemplos a seguir são de cargas de biblioteca não-secretura:

• No exemplo de código a seguir, o aplicativo procura "schannel.dll" usando o caminho de pesquisa menos seguro. Se um invasor puder colocar schannel.dll em CWD, ele será carregado mesmo antes de o aplicativo pesquisar os diretórios Windows para a biblioteca apropriada.

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

• No exemplo de código a seguir, o aplicativo tenta carregar a biblioteca dos vários locais do aplicativo e do sistema operacional descritos no início deste documento para a chamada LoadLibrary(). Se houver algum risco de o arquivo não estar presente, o aplicativo poderá tentar carregar o arquivo do diretório de trabalho atual. Esse cenário é um pouco menos perigoso do que o exemplo anterior. No entanto, ele ainda expõe o usuário do aplicativo a riscos se o ambiente não for completamente previsível.

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

Veja a seguir exemplos de cargas de biblioteca melhores e mais seguras:

• No exemplo de código a seguir, a biblioteca é carregada diretamente usando um caminho totalmente qualificado. Não há risco de o invasor introduzir código mal-intencionado, a menos que ele já tenha permissões de gravação no diretório de destino do aplicativo.
  
  

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

  
  
  Observação 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 exemplo de código a seguir, o diretório de trabalho atual é removido do caminho de pesquisa antes de chamar LoadLibrary. Isso reduz significativamente o risco, pois o invasor teria que controlar o diretório do aplicativo, o diretório Windows ou quaisquer diretórios especificados no caminho do usuário para usar um ataque de pré-carregamento de DLL.

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

• Em todos os sistemas que instalaram a atualização de segurança 963027 (descrita em MS09-014), o código a seguir moveria permanentemente o CWD para o último ponto na ordem de pesquisa. Todas as chamadas posteriores para a função SetSearchPathMode de dentro desse processo que tentar alterar o modo de pesquisa falharão.

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

• No exemplo de código a seguir, o diretório de trabalho atual é removido do caminho de pesquisa antes de chamar LoadLibrary. Isso reduz significativamente o risco, pois o invasor teria que controlar o diretório do aplicativo, o diretório do Windows ou qualquer diretório especificado no caminho do usuário para usar um ataque de pré-carregamento de DLL.

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