Administração do Windows

Dentro do kernel do Windows Vista: Parte 3

Mark Russinovich

 

Visão geral:

• Confiabilidade
• Recuperação
• Segurança

Até agora, esta série tem abordado os aprimoramentos do kernel do Windows Vista relacionados a processos, E/S, gerenciamento de memória, inicialização do sistema, desligamento e gerenciamento de energia. Nesta terceira parte

final, analisarei os recursos e aprimoramentos nas áreas de confiabilidade, recuperação e segurança.

Um recurso que não estou abordando nesta série é o Controle de Conta de Usuário (UAC, User Account Control), o qual envolve várias tecnologias diferentes, inclusive o sistema de arquivos e a virtualização do Registro de aplicativos herdados, consentimento de elevação para acesso a direitos administrativos e o mecanismo do Nível de Integridade do Windows®, a fim de isolar processos em execução com direitos administrativos dos processos com menos privilégios sendo executados na mesma conta. Para obter uma abordagem mais detalhada sobre as partes internas do UAC, fique atento a uma edição futura da TechNet Magazine.

O Windows Vista™ aprimora a confiabilidade do seu sistema, bem como a capacidade de diagnosticar problemas do sistema e de aplicativos por meio de vários novos recursos e aprimoramentos. Por exemplo, o agente de log do kernel do ETW (Event Tracing for Windows, rastreamento de eventos do Windows) está sempre ativo, gerando rastreamento de eventos de arquivos, Registro, interrupção e outros tipos de atividade em um buffer circular. Quando ocorre um problema, a nova WDI (Windows Diagnostic Infrastructure, Infra-estrutura de Diagnóstico do Windows) pode capturar um instantâneo do buffer e analisá-lo localmente ou carregá-lo no suporte da Microsoft para que seja solucionado.

O novo Monitor de confiabilidade e desempenho do Windows ajuda os usuários a correlacionarem erros, como falhas e interrupções, a alterações que tenham sido feitas na configuração do sistema. A poderosa SRT (System Repair Tool, ferramenta de reparo do sistema) substitui o Console de Recuperação para a recuperação offline de sistemas não inicializáveis.

Existem três áreas que dependem das alterações no nível do kernel no sistema e, portanto, merecem uma análise mais detalhada neste artigo: o KTM (Kernel Transaction Manager, gerenciador de transações de kernel), o tratamento aprimorado de falhas e as versões anteriores.

Gerenciador de Transações de Kernel

Um dos aspectos mais entediantes do desenvolvimento de software é o tratamento das condições de erro. Isso é especialmente válido se, durante a execução de uma operação de nível superior, um aplicativo concluiu uma ou mais subtarefas que resultaram em alterações no sistema de arquivos ou no Registro. Por exemplo, um serviço de atualização de software de um aplicativo pode efetuar várias atualizações do Registro, substituir um dos executáveis do aplicativo e, em seguida, ter o acesso negado quando tentar atualizar um segundo executável. Se o serviço não quiser permitir que o aplicativo resulte em um estado inconsistente, ele deverá rastrear todas as alterações feitas por ele e estar preparado para desfazê-las. O teste do código de recuperação de erro é difícil e, conseqüentemente, com freqüência é ignorado; portanto, os erros no código de recuperação podem negar o esforço.

Os aplicativos escritos para o Windows Vista podem, com muito pouco esforço, obter os recursos de recuperação automática de erro usando o novo suporte a transações no NTFS e no Registro com o Gerenciador de Transações de Kernel. Quando um aplicativo quiser efetuar determinado número de alterações relacionadas, ele pode criar uma transação do DTC (Distributed Transaction Coordinator, coordenador de transações distribuídas) e um identificador de transação do KTM diretamente e associar as modificações dos arquivos e das chaves do Registro à transação. Se todas as alterações tiverem êxito, o aplicativo confirma a transação e as alterações são aplicadas, mas a qualquer momento, até esse ponto, o aplicativo pode reverter a transação e as alterações serem descartadas.

Como vantagem adicional, outros aplicativos não visualizam as alterações feitas em uma transação até que ela seja confirmada; além disso, os aplicativos que utilizam o DTC no Windows Vista e na próxima versão do Windows Server®, cujo codinome é “Longhorn” podem coordenar as suas transações com o SQL Server™, Microsoft® Message Queue Server (MSMQ, servidor de enfileiramento de mensagens) e outros bancos de dados. Portanto, um serviço de atualização de aplicativo que utilize as transações do KTM nunca deixará o aplicativo em um modo inconsistente. É por esse motivo que o Windows Update e a Recuperação do Sistema utilizam as transações.

Como o núcleo do suporte à transação, o KTM permite que gerenciadores de recursos de transações, como o NTFS e o Registro, coordenem as suas atualizações em um conjunto específico de alterações feitas por um aplicativo. No Windows Vista, o NTFS utiliza uma extensão para oferecer suporte a transações denominadas TxF. O Registro utiliza uma extensão semelhante denominada TxR. Esses gerenciadores de recursos no modo kernel trabalham com o KTM para coordenar o estado da transação, justamente como os gerenciadores de recursos no modo de usuário utilizam o DTC para coordenar o estado da transação em vários gerenciadores de recursos no modo de usuário. Os terceiros também podem usar o KTM para implementar os seus próprios gerenciadores de recursos.

O TxF e o TxR definem um novo conjunto de sistema de arquivos e APIs do Registro que são semelhantes aos existentes, exceto pelo fato de incluírem um parâmetro de transação. Se um aplicativo quiser criar um arquivo em uma transação, ele primeiro utilizará o KTM para criar a transação e, em seguida, passará o identificador resultante da transação para a API de criação do novo arquivo.

O TxF e o TxR dependem da funcionalidade de registro em log do sistema de arquivos de alta velocidade do CLFS (Common Log File System, sistema de arquivos de log comum) (%SystemRoot%\System32\Clfs.sys), o qual foi introduzido no Windows Server 2003 R2. O TxR e o TxF utilizam o CLFS para armazenar permanentemente as alterações de estado de transações antes de confirmarem uma transação. Isso permite que eles forneçam recuperação de transações e garantias mesmo se houver queda de energia. Além do log do CLFS, o TxR cria um conjunto de arquivos de log relacionados, a fim de rastrear as alterações de transação no arquivo de Registro do sistema no %Systemroot%\System32\Config\Txr, como observado na Figura 1, bem como conjuntos separados de arquivos de log para cada hive de Registro de usuário. O TxF armazena dados de transações para cada volume em um diretório oculto no volume intitulado \$Extend\$RmMetadata.

Figura 1** Arquivos de log do TxR do hive de Registro do sistema  **(Clique na imagem para aumentar a exibição)

Suporte aprimorado a falhas

Quando o Windows detectar um erro irrecuperável no modo kernel – devido a um driver de dispositivo com bugs, hardware ou sistema operacional com falhas – ele tentará impedir a corrupção dos dados no disco interrompendo o sistema depois de exibir a famosa “Blue Screen of Death” (tela azul de erro) e, se configurado para tal, gravará o conteúdo de parte ou de toda a memória física em um arquivo de despejo de memória. Os arquivos de despejo são úteis, pois quando você reinicializa depois de uma falha, o serviço de Análise Online de Pane da Microsoft (OCA, Online Crash Analysis) pode analisá-los para descobrir a raiz do problema. Se você quiser, você mesmo pode analisá-los usando as Ferramentas de depuração da Microsoft para Windows).

No entanto, na versão anterior do Windows, o suporte aos arquivos de despejo de memória não era habilitado até que o Gerenciador de Sessão (%Systemroot%\System32\Smss.exe) processasse os arquivos de paginação inicializados. Isso significava que quaisquer erros críticos anteriores a esse ponto resultariam em uma tela azul, mas não em um arquivo de despejo. Como a carga da inicialização do driver de dispositivo ocorre antes de o Smss.exe iniciar, as falhas anteriores nunca resultariam em despejos de memória, tornando assim extremamente difícil o diagnóstico da causa.

O Windows Vista reduz o período de tempo em que nenhum arquivo de despejo é gerado ao inicializar o suporte ao arquivo de despejo depois que todos os drivers de dispositivo de inicialização tiverem sido inicializados, mas antes de carregar os drivers de início do sistema. Devido a essa alteração, se ocorrer uma falha durante a parte inicial do processo de reinicialização, o sistema pode capturar um despejo de memória, permitindo que a OCA ajude a resolver o problema. Além disso, o Windows Vista salva os dados em um arquivo de desejo em blocos de 64 KB, enquanto as versões anteriores do Windows os gravavam usando blocos de 4 KB. Essa alteração fez com que grandes arquivos de despejo fossem gravados 10 vezes mais rápido.

O tratamento de falhas de aplicativo também foi aprimorado no Windows Vista. Na versão anterior do Windows, quando um aplicativo falhava, ele executava um manipulador de exceção não tratada. O manipulador iniciava o processo de Relatório de Erros dos Aplicativos Microsoft (AER, Application Error Reporting) (%Systemroot%\System32\Dwwin.exe) para exibir uma caixa de diálogo indicando que o programa tinha falhado e lhe perguntando se desejaria enviar um relatório de erros à Microsoft. No entanto, se a pilha do segmento principal do processo tiver sido corrompida durante a falha, o manipulador de exceção não tratada falhou durante a execução, resultando no término do processo pelo kernel, o desaparecimento instantâneo das janelas do programa e na não exibição da caixa de diálogo de relatório de erros.

O Windows Vista move o tratamento de erros do contexto do processo de falha para um novo serviço intitulado WER (Windows Error Reporting, Relatório de Erros do Windows). Esse serviço é implementado por uma DLL (%Systemroot%\System32\Wersvc.dll) dentro do processo de Hospedagem do Serviço. Quando um aplicativo falha, ele ainda executa um manipulador de exceção não tratada, mas o manipulador envia uma mensagem para o serviço WER e ele inicia o processo de Relatório de Erros de Falha do WER (%Systemroot%\System32\Werfault.exe) para exibir a caixa de diálogo de relatório de erros. Se a pilha estiver corrompida e o manipulador de exceção não tratada falhar, ele executará novamente e falhará de novo, consumindo eventualmente toda a pilha do segmento (área de memória do zero), sendo que nesse ponto o kernel atuará e enviará a mensagem de notificação de falha ao serviço.

Você pode visualizar o contraste nessas duas abordagens nas Figuras 2 e 3, as quais mostram a relação de processo do Accvio.exe, um programa de teste que falha, e os processos de relatório de erros destacados em verde, no Windows XP e no Windows Vista. A nova arquitetura de tratamento de erros do Windows Vista significa que os programas não serão mais encerrados silenciosamente, sem oferecer a chance para que a Microsoft obtenha um relatório de erros e ajude os desenvolvedores de software a aprimorar os seus aplicativos.

Figura 2a** Tratamento de erros de aplicativo no Windows Vista **(Clique na imagem para aumentar a exibição)

Figura 2b(Clique na imagem para aumentar a exibição)

Figura 3a** Tratamento de erros de aplicativo no Windows Vista **(Clique na imagem para aumentar a exibição)

Figura 3b

VSS (Volume Shadow Copy, Cópia de Sombra de Volume)

O Windows XP introduziu uma tecnologia denominada Cópia de Sombra de Volume, a fim de criar instantâneos dos volumes de disco. Os aplicativos de backup podem usar esses instantâneos para criar imagens consistentes de backup, mas eles ficam ocultos da exibição e são mantidos somente durante o processo de backup.

Na verdade, os instantâneos não são cópias completas dos volumes. Em vez disso, eles são exibições de um volume de um ponto anterior, o qual consistia nos dados dinâmicos do volume recobertos com cópias de setores de volume, que tinham sido alterados desde a captura do instantâneo. O driver do Provedor de Instantâneo do Volume (%Systemroot\%System32\Drivers\Volsnap.sys) monitora as operações destinadas em volumes e efetua cópias dos setores antes de permitir que sejam alterados, armazenando os dados originais em um arquivo associado ao instantâneo no diretório de Informações de Volume do Sistema do volume.

O Windows Server 2003 exibia o gerenciamento de instantâneos aos administradores no servidor, e aos usuários nos sistemas cliente com as suas Cópias de Sombra de Pastas Compartilhadas. Esse recurso permitia instantâneos persistentes que os usuários podiam acessar, por meio da guia Versões Anteriores nas caixas de diálogo de propriedades do Explorer, para as suas pastas e arquivos localizados nos compartilhamentos de arquivo do servidor.

O recurso de Versões Anteriores do Windows Vista oferece esse suporte a todos os sistemas cliente, criando automaticamente instantâneos de volume, em geral uma vez ao dia, os quais você pode acessar por meio da caixa de diálogo de propriedades do Explorer, usando a mesma interface utilizada pelas Cópias de Sombra de Pastas Compartilhadas. Isso permite que você visualize, restaure ou copie as versões anteriores de arquivos e diretórios que possa ter acidentalmente modificado ou excluído. Apesar de essa não ser uma tecnologia nova do ponto de vista técnico, a implementação do recurso de Versões Anteriores do Windows Vista da Cópia de Sombra de Volume otimiza a do Windows Server 2003 para uso em ambientes da área de trabalho cliente.

O Windows Vista também aproveita os benefícios dos instantâneos de volume, a fim de unificar os mecanismos de proteção de dados do usuário e do sistema, bem como evitar salvar dados de backup redundantes. Quando uma alteração na instalação ou na configuração do aplicativo ocasiona comportamentos incorretos ou indesejados, você pode usar a Restauração do Sistema, um recurso introduzido na linha Windows NT® dos sistemas operacionais no Windows XP, a fim de restaurar os arquivos e dados do sistema para o seu estado anterior quando foi criado o ponto de restauração.

No Windows XP, a Restauração do Sistema utiliza um driver de filtro do sistema de arquivos – um tipo de driver que pode visualizar as alterações no nível de arquivos –, a fim de efetuar cópias de backup dos arquivos do sistema quando eles forem alterados. No Windows Vista, a Restauração do Sistema utiliza instantâneos de volume. Quando você utiliza a interface de usuário de Restauração do Sistema no Windows Vista para voltar a um ponto de restauração, na verdade você está copiando versões anteriores dos arquivos modificados do sistema a partir do instantâneo associado com o ponto de restauração para o volume dinâmico.

BitLocker

Até o momento, o Windows Vista é a versão mais segura do Windows. Além da inclusão do mecanismo de anti-spyware do Windows Defender, o Windows Vista introduz vários recursos de segurança e defesa em profundidade, inclusive a criptografia de volume completo BitLocker™, assinatura de código para o modo kernel, processos protegidos, randomização de carga de espaço de endereço e aprimoramentos no Controle de Conta de Usuário e na segurança do serviço do Windows.

Um sistema operacional pode reforçar somente as suas políticas de segurança enquanto estiver ativo, de forma que você precisará tomar medidas adicionais para proteger os dados quando a segurança física de um sistema estiver comprometida e os dados possam ser acessados de fora do sistema operacional. Os mecanismos baseados em hardware, como senhas de BIOS e criptografia, são duas tecnologias comumente utilizadas para impedir o acesso não autorizado, especialmente em laptops, os quais têm grande probabilidade de serem perdidos ou roubados.

O Windows 2000 introduziu o Sistema de arquivos com criptografia (EPS, Encrypting File System) e, na sua versão do Windows Vista, o EFS inclui vários aprimoramentos em relação às implementações anteriores, inclusive aprimoramentos de desempenho, suporte à criptografia do arquivo de paginação e armazenamento de chaves de EFS de usuário em cartões inteligentes. No entanto, não é necessário usar o EFS para proteger o acesso a áreas confidenciais do sistema, como os arquivos de hive do Registro. Por exemplo, se a Diretiva de grupo permitir que você faça logon no seu laptop mesmo quando você não estiver conectado a um domínio, os verificadores de credencial de domínio estarão armazenados em cache no Registro; portanto, um invasor poderia usar as ferramentas para obter o hash de senha da conta de domínio e usá-la para tentar obter a sua senha com um cracker de senha. A senha forneceria acesso à sua conta e os arquivos de EFS (supondo-se que você não tenha armazenado a chave de EFS em um cartão inteligente).

Para facilitar a criptografia do volume completo de reinicialização (o volume com o diretório do Windows), inclusive todos seus arquivos e dados do sistema, o Windows Vista introduz um recurso de criptografia de volume completo intitulado Criptografia de Unidade de Disco do Windows. Ao contrário do EFS, que é implementado pelo driver do sistema de arquivos NTFS e opera no nível de arquivos, o BitLocker efetua a criptografia no nível do volume usando o driver de FVE (Full Volume Encryption, criptografia de volume completo) (%Systemroot%\System32\Drivers\Fvevol.sys) como apresentado na Figura 4.

Figura 4** Driver de filtro FVE do BitLocker **(Clique na imagem para aumentar a exibição)

O FVE é um driver de filtro, de forma que ele visualiza automaticamente todas as solicitações de E/S que o NTFS envia para o volume, criptografando blocos como eles são gravados e os descriptografando como eles são lidos, usando a FVEK (Full Volume Encryption Key, chave de criptografia de volume completo) atribuída ao volume quando ele for inicialmente configurado para usar o BitLocker. Por padrão, os volumes são criptografados usando uma chave AES de 128 bits e uma chave difusora de 128 bits. Como a criptografia e descriptografia ocorrem abaixo do NTFS no sistema de E/S, o volume aparece como NTFS como se estivesse descriptografado e o NTFS não precisa nem mesmo ter conhecimento de que o BitLocker está habilitado. No entanto, se você tentar ler os dados a partir do volume fora do Windows, ele aparecerá como dados aleatórios.

A FVEK é criptografada com uma VMK (Volume Master Key, chave mestra de volume) e armazenada em uma região especial de metadados do volume. Quando você configurar o BitLocker, você terá várias opções para a proteção da VMK, dependendo dos recursos de hardware do sistema. Se o sistema tiver um TPM (Trusted Platform Module, módulo de plataforma confiável) que esteja de acordo com a v1.2 da especificação do TPM e tiver suporte a BIOS associado, você pode criptografar a VMK com a TPM, fazer com que o sistema criptografe a VMK usando uma chave armazenada no TPM e uma armazenada em um dispositivo flash USB, ou criptografar a chave usando uma chave armazenada no TPM e um número de identificação pessoal que você digitará quando o sistema for reinicializado. Para sistemas que não tenham um TPM, o BitLocker oferece a opção de criptografia da VMK usando uma chave armazenada em um dispositivo flash USB externo. Em qualquer caso, você precisará de um volume de sistema NTFS de 1,5 GB descriptografado, o volume no qual o Gerenciador de inicialização e o BCD (Boot Configuration Database, banco de dados de configuração de inicialização) estão armazenados.

A vantagem de usar um TPM é que o BitLocker utiliza recursos do TPM, a fim de garantir que ele não descriptografará a VKM, nem desbloqueará o volume de inicialização se o BIOS ou os arquivos de reinicialização do sistema tiverem sido alterados desde que o BitLocker tiver sido habilitado. Quando você criptografar o volume do sistema pela primeira vez e sempre que executar atualizações em qualquer um dos componentes mencionados, o BitLocker calculará hashes SHA-1 desses componentes e armazenará cada hash, denominado uma medida, nos diferentes PCRs (Platform Configuration Registers, registros de configuração de plataforma) do TPM com a ajuda do driver de dispositivo do TPM (%Systemroot%\System32\Drivers\Tpm.sys). Em seguida, ele utiliza o TPM para lacrar a VKM, uma operação que utiliza uma chave particular armazenada no TPM, a fim de criptografar a VMK e os valores armazenados nos PCRs, juntamente com outros dados que o BitLocker passar para o TPM. O BitLocker armazenará então a VMK lacrada e a FVEK criptografada na região de metadados do volume.

Quando o sistema for inicializado, ele medirá seu próprio hash e código de carregamento de PCR, e gravará o hash no primeiro PCR do TPM. Em seguida, ele executará o hash do BIOS e armazenará a medição no PCR apropriado. O BIOS, por sua vez, efetua o hash no próximo componente na seqüência da inicialização, o MBR (Master Boot Record, registro mestre de inicialização) do volume de inicialização, e esse processo continuará até que o carregador do sistema operacional seja medido. Cada parte subseqüente do código executada será responsável por medir o código carregado, bem como por armazenar essa medição no registro apropriado no TPM. Finalmente, quando o usuário selecionar qual sistema operacional deseja inicializar, o Gerenciador de inicialização (Bootmgr) lerá a VMK criptografada a partir do volume e solicitará que o TPM a desbloqueie. Somente se todas as medições forem as mesmas de quando a VMK foi lacrada, inclusive o número de identificação pessoal opcional, o TPM terá êxito ao descriptografar a VMK.

Você pode pensar nesse esquema como uma cadeia de verificação, na qual cada componente na seqüência de inicialização descreve o próximo componente para o TPM. O TPM somente divulgará o seu segredo se todas as descrições corresponderem aos originais fornecidos. Portanto, o BitLocker protege os dados criptografados mesmo quando o disco for removido e inserido em outro sistema, quando o sistema for inicializado usando um diferente sistema operacional ou quando os arquivos não criptografados no volume de inicialização estiverem comprometidos.

Verificação de integridade do código

O malware implementado como um driver de dispositivo no modo kernel, inclusive rootkits, é executado no mesmo nível de privilégio que o kernel e, portanto, sua identificação e remoção são mais difíceis. Tal malware pode modificar o comportamento do kernel e outros drivers, ao ponto de se tornarem praticamente invisíveis. A integridade de código do Windows Vista para o recurso de código do modo kernel, também conhecida como assinatura de código no modo kernel (KMCS, Kernel-Mode Code Signing), também permite que os drivers de dispositivo sejam carregados, caso tenham sido publicados e assinados digitalmente por desenvolvedores que tenham sido verificados por algumas das autoridades de certificação (CAs, Certificate Authorities). A KMCS é reforçada, por padrão, no Windows Vista para sistemas de 64 bits.

Como as autoridades de certificação cobram uma taxa por seus serviços e executam verificações básicas em segundo plano, como verificar uma identidade comercial, é mais difícil produzir malware anônimo no modo kernel que seja executado no Windows Vista de 64 bits. Além disso, o malware que consegue escapar pelo processo de verificação pode potencialmente deixar pistas que, quando o malware for detectado em um sistema comprometido, levem ao autor. A KMCS também apresenta usos secundários, como fornecer as informações de contato para a equipe de Análise Online de Pane da Microsoft quando houver suspeita de que um driver tem um bug que está causando falha nos sistemas dos clientes, bem como desbloquear conteúdo de multimídia de alta definição, o qual descreverei em seguida.

A KMCS utiliza tecnologias de criptografia de chave pública, as quais têm sido utilizadas há mais de uma década pelo Windows, e requer que o código no modo kernel inclua uma assinatura digital gerada por uma das autoridades de certificação confiáveis. Se um editor enviar um driver para o WHQL (Windows Hardware Quality Laboratory, laboratório de qualidade de hardware do Windows) da Microsoft e o driver passar pelo teste de confiabilidade, a Microsoft atuará como a autoridade de certificação que assinará o código. A maioria dos editores obterá assinaturas por meio do WHQL, mas quando um driver não tiver um programa de teste do WHQL, o editor não desejará submetê-lo aos testes do WHQL, ou se o driver for um driver de reinicialização, o qual seja carregado antecipadamente na inicialização do sistema, os editores devem eles mesmos assinar o código. Para fazer isso, eles primeiro devem obter um certificado de assinatura de código a partir de uma das autoridades de certificação que a Microsoft tenha identificado como confiável para a assinatura do código no modo kernel. O autor então efetuará o hash do código digitalmente, assinará o hash o criptografando com uma chave particular e incluirá o certificado e o hash criptografado com o código.

Quando um driver tentar ser carregado, o Windows descriptografará o hash incluído no código usando a chave particular armazenada no certificado e, em seguida, verificará se o hash corresponde àquele incluído no código. A autenticidade do certificado será verificada da mesma forma, porém usando a chave pública da autoridade de certificação, a qual está incluída no Windows.

O Windows também verifica a cadeia do certificado associado em até uma das autoridades raiz, as quais são incorporadas no carregador de inicialização do Windows e no kernel do sistema operacional. As tentativas de carregar um driver de 64 bits não assinado nunca ocorrem em um sistema de produção, ao contrário do Plug and Play Manager, que exibe uma caixa de diálogo de aviso quando é direcionado para carregar um driver, o qual não apresenta uma assinatura confirmando que passou pelos testes do WQHL, o Windows Vista de 64 bits grava silenciosamente um evento no log de eventos do aplicativo de Integridade do Código, como o apresentado na Figura 5, sempre que ele bloquear o carregamento de um driver não assinado. O Windows Vista de 32 bits também verifica as assinaturas do driver, mas permite que os drivers não assinados sejam carregados. O bloqueio dos drivers interromperia os sistemas atualizados do Windows XP que exigem que os drivers sejam carregados no Windows XP; além disso, permite suporte para hardware para o qual existem somente drivers do Windows XP. No entanto, o Windows de 32 bits também grava eventos no log de eventos do Código de Integridade quando ele carrega um driver não assinado.

Figura 5** Eventos de tentativa de carregamento de driver não assinado **(Clique na imagem para aumentar a exibição)

Como a assinatura de código é comumente utilizada para rotular o código como uma versão oficial rigorosamente testada, os editores geralmente não querem assinar o código de teste. Por esse motivo, o Windows Vista inclui um modo de assinatura de teste que você pode habilitar e desabilitar com a ferramenta Bcdedit (descrita em meu artigo de março de 2007 da TechNet Magazine), onde os drivers no modo kernel assinados digitalmente serão carregados com um certificado de teste gerado por uma autoridade de certificação interna. Esse modo foi desenvolvido para uso pelos programadores durante o desenvolvimento de seus códigos. Quando o Windows estiver nesse modo, ele exibirá marcadores na área de trabalho, como o apresentado na Figura 6.

Figura 6** Modo de assinatura de teste do Windows Vista **

Processos protegidos

O conteúdo de multimídia da próxima geração, como o HD-DVD, BluRay e outros formatos licenciados sob o AACS (Advanced Access Content System, sistema de conteúdo de acesso avançado), serão cada vez mais comuns nos próximos anos. O Windows Vista inclui várias tecnologias, coletivamente denominadas PMP (Protected Media Path, caminho de mídia protegida), as quais são exigidas pelo padrão do AACS para que tal conteúdo seja reproduzido. O PMP inclui o PUMA (Protected User-Mode Audio, áudio no modo de usuário protegido) e o PVP (Protected Video Path, caminho de vídeo protegido), os quais juntos fornecem mecanismos para drivers de áudio e vídeo, bem como aplicativos de reprodução de mídia, a fim de impedir que software ou hardware não autorizado capture conteúdo na forma de alta definição.

O PUMA e o PVP definem interfaces e oferecem suporte a reprodutores de áudio e vídeo, drivers de dispositivo e hardware, mas o PMP também depende de um mecanismo geral do kernel, introduzido no Windows Vista, denominado processo protegido. Os processos protegidos têm como a construção do processo padrão do Windows, a qual encapsula uma imagem executável em execução, suas DLLs, o contexto de segurança (a conta na qual o processo está em execução e seus privilégios de segurança) e os segmentos que executam o código no processo, mas impedem determinados tipos de acesso.

Os processos padrão implementam um modelo de controle de acesso, o qual permite total acesso ao proprietário do processo e a contas administrativas com o privilégio de Depurar programas. O acesso total permite que um usuário visualize e modifique o espaço do endereço do processo, inclusive o código e os dados mapeados do processo. Os usuários também podem injetar segmentos no processo. Esses tipos de acessos não são consistentes com as exigências do PMP, pois eles permitiriam que um código não autorizado obtivesse acesso a conteúdo de alta definição e a chaves de DRM (Digital Rights Management, gerenciamento de direitos digitais) armazenadas em um processo que está reproduzindo o conteúdo.

Os processos protegidos restringem o acesso a um conjunto limitado de interfaces de informação e de gerenciamento do processo, as quais incluem consulta do nome da imagem do processo e conclusão ou suspensão do processo. Entretanto, o kernel apresenta informações diagnósticas para processos protegidos disponíveis pro meio de funções de consulta do processo em geral, as quais retornam dados relativos a todos os processos em um sistema e, portanto, não requerem acesso direto ao processo. Os acessos que poderiam comprometer a mídia são permitidos somente pelos outros processos protegidos.

Além disso, para impedir esse comprometimento, todos os códigos executáveis carregados em um processo protegido, inclusive sua imagem executável e as DLLs, devem ser assinados pela Microsoft (WHQL) com um sinalizador de PE (Protected Environment, ambiente protegido), ou no caso de codec de áudio, assinado pelo desenvolvedor com um certificado de assinatura de DRM obtido da Microsoft. Como o código no modo kernel pode obter acesso total a qualquer processo, inclusive aos processos protegidos, e o Windows de 32 bits permite que o código no modo kernel não assinado seja carregado, o kernel fornece uma API para processos protegidos, a fim de consultar o “nível de correção” do ambiente no modo kernel e utilizar o resultado para desbloquear conteúdo premium, somente se não houver código não assinado carregado.

Identificando um processo protegido

Não há APIs que identifiquem especificamente os processos protegidos, mas você pode identificá-las indiretamente com base nas informações limitadas disponíveis para elas, bem como por meio de sua incapacidade de depurá-las até mesmo a partir de uma conta administrativa. O processo de Isolamento de Gráfico de Dispositivo de Áudio (%Systemroot%\System32\Audiodg.exe) é utilizado para reproduzir DVDs codificados com CSS (Content Scramble System) e é identificável como um processo protegido no painel do Gerenciador de tarefas, devido ao fato de o gerenciador não conseguir obter sua linha de comando, virtualização e status de prevenção de execução de dados, até mesmo quando em execução com direitos administrativos.

Visualização do gerenciador de tarefas do processo protegido audiodg(Clique na imagem para aumentar a exibição)

ASLR (Address Space Load Randomization)

Apesar das medidas como a prevenção de execução de dados e da verificação de erros do compilador avançado, os autores de malware continuam encontrando vulnerabilidades de estouro de buffer, as quais permitem que eles infectem processos em rede, como o Internet Explorer®, serviços do Windows e aplicativos de terceiros, a fim de obter acesso a um sistema. No entanto, assim que eles tiverem infectado um processo, eles devem usar as APIs do Windows para concluir sua meta final de ler os dados do usuário ou estabelecer uma presença permanente por meio da modificação das configurações do usuário ou do sistema.

A conexão de um aplicativo com pontos de entrada de API exportados pelas DLLs geralmente é algo tratado pelo carregador do sistema operacional, mas esses tipos de infecção de malware não aproveitam os benefícios dos serviços do carregador. Isso não apresenta um problema para malware não versões anteriores do Windows, pois para qualquer versão do Windows, as imagens executáveis do sistema e DLLs sempre são carregadas no mesmo local, permitindo que o malware pressuponha que as APIs residem nos endereços fixos.

O recurso de ASLR do Windows Vista não permite que o malware saiba onde as APIs estão localizadas. Isso é feito por meio do carregamento das DLLs e dos executáveis do sistema em local diferente sempre que o sistema for inicializado. No início do processo de inicialização, o Gerenciador de memória seleciona uma compensação de carregamento de imagem de DLL aleatória a partir de um dos 256 endereços alinhados de 64 KB, na região de 16 MB na parte superior do espaço de endereço no modo de usuário. Como as DLLs que têm novo sinalizador de realocação dinâmica no seu cabeçalho de imagem são carregadas no processo, o Gerenciador de memória as empacota na memória, iniciando no endereço de compensação de carregamento da imagem e seguindo o fluxo descendente.

Os executáveis com o sinalizador definido obtêm um tratamento semelhante, sendo carregados em um ponto aleatório alinhado de 64 KB em 16 MB do endereço de carregamento base armazenado em seu cabeçalho de imagem. Além disso, se determinada DLL ou executável for carregado novamente depois de ter sido descarregado por todos os processos utilizando essa DLL ou executável, o Gerenciador de memória selecionará novamente um local aleatório no qual carregá-lo. A Figura 7 mostra um exemplo de layout do espaço de endereço para um sistema de 32 bits do Windows Vista, inclusive as áreas das quais o recurso de ASLR seleciona a compensação de carregamento de imagem e o endereço de carregamento do executável.

Figura 7** Efeito do ASLR em endereços de carregamento de DLL e executável **(Clique na imagem para aumentar a exibição)

Somente as imagens com sinalização de realocação dinâmica, o que inclui todas as DLLs e executáveis do Windows Vista, obtêm realocação, pois o fato de mover as imagens herdadas poderia interromper as suposições internas que os desenvolvedores fizeram sobre onde suas imagens seriam carregadas. O Visual Studio® 2005 SP1 acrescenta suporte para a definição do sinalizador, de forma que os desenvolvedores de terceiros podem ter proveito total do ASLR.

A randomização dos endereços de carregamento de DLL para um dos 256 locais não impede que um malware adivinhe a localização correta de uma API, mas prejudica seriamente a velocidade na qual um worm de rede pode se propagar e impede que o malware, que tenha somente uma chance de infectar o sistema, funcione de forma confiável. Além disso, a estratégia de realocação de ASLR tem um benefício secundário de os espaços de endereço serem empacotados com mais rigidez do que nas versões anteriores do Windows, criando regiões maiores de memória livre para as alocações de memória contíguas, reduzindo o número de tabelas de página que o Gerenciador de memória aloca para controlar o layout de espaço do endereço e minimizando as falhas do TLB (Translation Lookaside Buffer, buffer de conversão à parte).

Aprimoramentos da segurança de serviço

Os serviços do Windows são alvos ideais para malware. Muitos oferecem acesso de rede à sua funcionalidade, expondo possivelmente acesso explorável remotamente a um sistema; a maioria é executada com mais privilégios do que as contas de usuário padrão, oferecendo a chance para elevar os privilégios em um sistema local se puderem ser comprometidos por malware. Por esse motivo, o Windows começou a evoluir com alterações feitas no Windows XP SP2, o que reduziu os privilégios e o acesso atribuído aos serviços para somente os necessários para suas funções. Por exemplo, o Windows XP SP2 introduziu as contas de Serviço Local e Serviço de Rede, as quais incluem somente um subconjunto dos privilégios disponíveis para a conta em que os serviços eram sempre executados anteriormente, o Sistema Local. Isso minimiza o acesso que um invasor pode conseguir ao explorar um serviço.

Vendo o ASLR em ação

Você pode observar facilmente os efeitos do ASLR ao comparar os endereços de carregamento de DLL para um processo em duas sessões diferentes de inicialização usando uma ferramenta, como Process Explorer da Sysinternals. Nessas duas capturas de tela, obtidas de duas sessões diferentes, a Ntdll.dll foi carregada no Explorer primeiro no endereço 0x77A30000 e, em seguida, no endereço 0x77750000.

Diferentes endereços base para ntdll.dll(Clique na imagem para aumentar a exibição)

Diferentes endereços base para ntdll.dll(Clique na imagem para aumentar a exibição)

No meu artigo anterior, descrevi como os serviços são executados isoladamente das contas de usuários em sua própria sessão, mas o Windows Vista também amplia o seu uso do princípio de privilégios mínimos ao reduzir ainda mais os privilégios e acessos a arquivos, chaves de Registro e portas de firewall que atribui para a maioria dos serviços. O Windows Vista define uma nova conta de grupo, denominada Identificador de segurança do serviço (Service Security Identifier), exclusiva para cada serviço. O serviço pode definir permissões em seus recursos, de forma que somente o seu SID de serviço tenha acesso, impedindo que outros serviços executados na mesma conta de usuário tenham acesso se um serviço ficar comprometido. Você pode ver um SID de serviço ao usar o comando sc showsid, seguido pelo nome de serviço, como mostrado na Figura 8.

Figura 8** Visualizando um SID de serviço **(Clique na imagem para aumentar a exibição)

Os SIDs de serviço protegem o acesso aos recursos de propriedade de um determinado serviço, mas por padrão os serviços ainda têm acesso a todos os objetos que a conta de usuário, na qual são executados, pode acessar. Por exemplo, um serviço sendo executado na conta de Serviço Local pode não conseguir acesso a recursos criados por outro serviço sendo executado como Serviço Local em um processo diferente, o qual tenha protegido seus objetos com permissões fazendo referência a um SID de serviço; no entanto, ele ainda pode ler e gravar quaisquer objetos aos quais o Serviço Local (e quaisquer grupos aos quais o Serviço Local pertence, como o grupo de Serviço) tenha permissões.

O Windows Vista introduz um novo tipo de serviço restrito chamado de serviço de gravação restrita, o qual permite que um serviço grave somente o acesso a objetos acessíveis ao seu SID de serviço, a todos no grupo e ao SID atribuído na sessão de logon. Para realizar isso, ele utiliza SIDs restritos, um tipo de SID introduzido novamente no Windows 2000. Quando o processo de abertura de um objeto for um serviço de gravação restrita, o algoritmo de verificação do acesso será alterado, de forma que um SID que não tenha sido atribuído a um processo, tanto nas formas restritas e não restritas, não poderá ser utilizado para conceder ao processo acesso de gravação a um objeto. Você pode ver se um serviço está restrito com o comando a seguir:

sc qsidtype [service]

Outra alteração facilita que um serviço impeça que outros serviços sendo executados na mesma conta tenham acesso aos objetos que ele criar. Nas versões anteriores do Windows, o criador de um objeto também é o seu proprietário, e os proprietários têm a capacidade de ler e alterar as permissões de seus objetos, permitindo que tenham acesso total aos seus próprios objetos. O Windows Vista introduz o novo SID de Direitos do Proprietário, o qual, se presente nas permissões de um objeto, pode limitar os acessos de um proprietário ao seu próprio objeto, mesmo removendo o direito de definir e consultar as permissões.

Um aprimoramento adicional ao modelo de segurança do serviço no Windows Vista permite que um desenvolvedor do serviço especifique exatamente quais privilégios de segurança o serviço precisa para operar, quando o serviço for registrado em um sistema. Por exemplo, se o serviço precisar gerar eventos de auditoria, ele deveria listar o privilégio de auditoria.

Quando o Gerenciador de controle de serviço iniciar um processo que hospede um ou mais serviços do Windows, ele cria um token de segurança (o objeto kernel que lista uma conta de usuário do processo, associações de grupo e privilégios de segurança) para o processo, o qual inclui somente os privilégios exigidos pelos serviços no processo. Se um serviço especificar um privilégio que não esteja disponível na conta na qual é executado, o serviço apresentará falha ao iniciar. Quando nenhum dos serviços em execução em um processo de conta de Serviço Local precisar do privilégio de Depurar programas, por exemplo, o Gerenciador de controle de serviço distribui esse privilégio a partir do token de segurança do processo. Dessa forma, se o processo de serviço estiver comprometido, o código malicioso não poderá aproveitar os privilégios que não tiverem sido explicitamente solicitados pelos serviços em execução no processo. O comando sc qprivs relata os privilégios que um serviço tenha solicitado.

Conclusão

Este artigo conclui a terceira parte da análise das alterações no kernel do Windows Vista. Há recursos e aprimoramentos que não foram abordados ou mencionados, como um novo pool de segmentos de trabalho para desenvolvedores de aplicativos, novos mecanismos de sincronização, como bloqueios de leitura/gravação compartilhada, marcação de segmento do serviço, suporte para verificação de disco NTFS online e redimensionamento de volume e um novo mecanismo de IPC de kernel denominado ALPC (Advanced Local Procedure Call, chamada avançada de procedimento local). Para obter mais informações sobre esses e outros recursos, consulte a próxima edição do Windows Internals, com previsão de publicação no final de 2007.

Visualizando o serviço de gravação restrita

Somente um processo de hospedagem de serviço no Windows Vista hospeda serviços restritos. Você pode identificá-lo com uma ferramenta de visualização de processo, como o Process Explorer, como a que possui a linha de comando:

svchost -k LocalServiceNoNetwork

Os serviços configurados para execução nesse processo incluem o Mecanismo de Filtragem Base, o Serviço de Diretiva de Diagnóstico, o Firewall do Windows, Logs e alertas de desempenho e o Windows Media® Center Service Starter.

Esta tela mostra o formato textual do SID do serviço de Mecanismo de Filtragem Base, NT SERVICE\BFE, listado uma vez com a sinalização Restrito e novamente sem ela, de forma que o processo tenha acesso a recursos acessíveis a essa conta. No entanto, ele não tem acesso necessariamente a outros objetos em geral acessíveis à conta de Serviço Local. Por exemplo, como a conta NT AUTHORITY\SERVICE não aparece no token do processo com o sinalizador restrito, o processo não pode modificar os objetos que concedem acesso de gravação somente a tal conta, mas não a outras contas no token que tenham o sinalizador restrito.

Os serviços em execução nesse processo também limitam os privilégios, pois os privilégios listados na parte inferior da caixa de diálogo de propriedades são um subconjunto dos privilégios disponíveis para a conta de Serviço Local.

Sinalizadores de SID em um serviço(Clique na imagem para aumentar a exibição)

Mark Russinovich é um colega da área técnica da Microsoft na divisão de plataforma e serviços. Ele é co-autor do livro Microsoft Windows Internals (Microsoft Press, 2004) e palestrante assíduo em conferências de desenvolvedores e TI, inclusive da Microsoft Tech•Ed e de PDC. Russinovich uniu-se à Microsoft com a aquisição da empresa de que foi co-fundador, a Winternals Software. Ele também criou a Sysinternals, onde publicou utilitários muito populares, inclusive o Process Explorer, o Filemon e o Regmon.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..