Entrar com a conta da Microsoft
Entre ou crie uma conta.
Olá,
Selecione uma conta diferente.
Você tem várias contas
Escolha a conta com a qual você deseja entrar.

O suporte para Windows Vista Service Pack 1 (SP1) termina em 12 de julho de 2011. Para continuar recebendo atualizações de segurança do Windows, verifique se o Windows Vista com Service Pack 2 (SP2) está sendo executado. Para obter mais informações, consulte esta página da Web da Microsoft: O suporte está terminando para algumas versões do Windows.

Quando um aplicativo carrega dinamicamente uma DLL (biblioteca de links dinâmicos) sem especificar um caminho totalmente qualificado, Windows tenta localizar a DLL pesquisando um conjunto bem definido de diretórios. Se um invasor ganhar o controle de um dos diretórios, ele poderá forçar o aplicativo a carregar uma cópia mal-intencionada da DLL em vez da DLL que estava esperando. Esses ataques são conhecidos como "ataques de pré-carregamento de DLL" e são comuns a todos os sistemas operacionais que suportam o carregamento dinâmico de bibliotecas DLL compartilhadas. O efeito desses ataques pode ser que um invasor possa executar código no contexto do usuário que está executando o aplicativo. Quando o aplicativo está sendo executado como Administrador, isso pode levar a uma elevação local de privilégio. Sabemos sobre o interesse renovado nesses ataques. Para limitar o efeito que esse problema tem em nossos clientes mútuos, estamos liberando esse documento para a comunidade de desenvolvedores para garantir que eles saibam sobre esse problema e tenham as ferramentas necessárias para resolver o problema em seus aplicativos.

Resumo

Descrição dos 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.

Etapas recomendadas para desenvolvedores de software

Recomendamos que os desenvolvedores faça o seguinte:

  • Valide seus aplicativos para instâncias de cargas de biblioteca não-título (exemplos de cada um são dados posteriormente neste artigo). Eles incluem o seguinte:

    • O uso do SearchPath para identificar o local de uma biblioteca ou componente.

    • O uso de LoadLibrary para identificar a versão do sistema operacional.

  • Use caminhos totalmente qualificados para todas as chamadas para LoadLibrary, CreateProcess e ShellExecute onde você pode.

  • Implemente chamadas para SetDllDirectory com uma cadeia de caracteres vazia ("") para remover o diretório de trabalho atual da ordem de pesquisa DLL padrão onde é necessário. Esteja ciente de que SetDllDirectory afeta todo o processo. Portanto, você deve fazer isso uma vez no início da inicialização do processo, não antes e depois das chamadas para LoadLibrary. Como SetDllDirectory afeta todo o processo, vários threads chamando SetDllDirectory com valores diferentes podem causar comportamento indefinido. Além disso, se o processo for projetado para carregar DLLs de terceiros, os testes serão necessários para determinar se a configuração em todo o processo causará incompatibilidades. Um problema conhecido é que, quando um aplicativo depende Visual Basic for Applications, uma configuração em todo o processo pode causar incompatibilidades.

  • Use a função SetSearchPathModepara habilitar o modo de pesquisa de processo seguro para o processo. Isso move o diretório de trabalho atual para o último lugar na lista de pesquisa do SearchPath durante o tempo de vida do processo.

  • Evite usar o SearchPath para verificar a existência de uma DLL sem especificar um caminho totalmente qualificado, mesmo que o modo de pesquisa seguro esteja habilitado, porque isso ainda pode levar a ataques de Pré-carregamento de DLL.

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");

Usando o Monitor de Processo para detectar dinamicamente cargas não-secreções

A Microsoft publica uma ferramenta chamada Monitor de Processo. Essa ferramenta permite que os desenvolvedores e administradores acompanhem de perto o comportamento de um processo em execução. O Monitor de Processo pode ser usado para detectar dinamicamente se um de seus aplicativos pode estar vulnerável a esse tipo de problema.

  • Para baixar o Monitor de Processo, visite a seguinte página da Web da Microsoft:

    http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

  • Tente iniciar seu aplicativo usando o conjunto CWD para um diretório específico. Por exemplo, clique duas vezes em um arquivo que tenha uma extensão cujo manipulador de arquivos é atribuído ao seu aplicativo.

  • Configurar o Monitor de Processo com os seguintes filtros:



    texto alternativo

  • Se um caminho vulnerável estiver sendo atingido, você verá algo semelhante ao seguinte: texto alternativoA chamada para o compartilhamento de arquivos remotos para carregar uma DLL indica que esse é um programa

    vulnerável.

Informações adicionais

Para obter mais informações, visite as seguintes páginas da Web da Microsoft: Ordem de Pesquisa da

Biblioteca de Links Dinâmicos

http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspxDocumentação MSDN na função SearchPath

http://msdn.microsoft.com/en-us/library/aa365527(VS.85).aspxDocumentação MSDN na função LoadLibrary

http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspxDocumentação MSDN na função SetDllDirectory

http://msdn.microsoft.com/en-us/library/ms686203(VS.85).aspxDocumentação MSDN na função SetSearchPathMode

http://msdn.microsoft.com/en-us/library/dd266735(VS.85).aspxPostagem de blog por David Leblanc, Engenheiro de Segurança Principal com Microsoft Office

http://blogs.msdn.com/b/david_leblanc/archive/2008/02/20/dll-preloading-attacks.aspxPostagem de blog por Andrew Roths, equipe de Engenharia do MSRC em ataques de pré-carregamento de DLL

http://blogs.technet.com/b/srd/archive/2009/04/14/ms09-014-addressing-the-safari-carpet-bomb-vulnerability.aspx

Recursos adicionais

Precisa de mais ajuda?

Expanda suas habilidades
Explore o treinamento
Obtenha novos recursos primeiro
Ingressar no Microsoft Insider

Essas informações foram úteis?

Qual é o seu grau de satisfação com a qualidade do idioma?
O que afetou sua experiência?

Obrigado pelos seus comentários!

×