No Windows Vista o UAC apenas podia ser ligado ou desligado. Isso não parece um grande problema, mas ocorre que os usuários não gostavam do volume de perguntas realizadas pelo UAC, acabando por gerar uma imagem ruim para o sistema operacional como um todo.

É importante ainda ressaltar que a tela utilizada para solicitar a elevação de privilégios no Windows Vista é uma tela tão segura que nenhum software de captura de tela consegue captura-la - quanto mais manipula-la.

Como "solução" para isso, o excesso de pedidos de elevação, a Microsoft criou 4 níveis de configuração do UAC :

• Desligado : Neste caso nenhuma proteção é realizada
• Ligado apenas para programas de 3os, sem tela segura : A proteção vale para aplicações de terceiros tentando acessar recursos do sistema operacional. A elevação é feita sem a tela segura típica do UAC
• Ligado apenas para programas de 3os, com tela segura : A proteção vale para aplicações de terceiros tentando acessar recursos do sistema operacional. A elevação é feita com tela segura.
• Ligado para tudo : Tem a mesma funcionalidade da configuração de UAC ligado do Windows Vista

O problema encontra-se exatamente nos níveis intermediários que foram criados, sendo que a opção default é fazer a pergunta de elevação apenas para programas de 3os com tela segura, teoricamente a mais baixa opção sem risco.

A diferença entre os níveis intermediários, como podemos notar, é a tela de segurança. Em um deles é utilizada a mesma tela altamente segura que no Windows Vista. Já no outro é utilizada uma tela mais tradicional e consequentemente menos segura.

Com estas mudanças, 2 bugs foram encontrados.

Bug No 1 : Mudança do nível do UAC

O primeiro bug é o fato da janela de configuração do UAC e a mudança do UAC em si não exigir elevação.

Foi demonstrado, através de scripts, que uma aplicação maliciosa poderia mudar o nível do UAC sem o usuário perceber e tomar o controle da máquina, o que é uma falha de segurança séria.

Depois de muita discussão de toda a comunidade que está testando o SO com a própria Microsoft, finalmente a Microsoft informou que irá alterar essas características e as mudanças serão vistas na edição Release Candidate do Windows 7. Um problema a menos.

Bug No 2 : Aplicações elevando-se silenciosamente

Para entendermos como funciona este bug precisamos nos fazer uma pergunta e decifrar aos poucos a resposta.

Pergunta : Nos dois níveis intermediários, o Windows 7 promete não pedir elevação quando o próprio usuário estiver configurando o SO, mas pedir quando outros programas tentarem o mesmo. Como ele distingue entre o próprio usuário e outros programas ?

Primeiramente, é preciso destacar que a elevação continua acontecendo em todos os casos. Basta observar o funcionamento técnico do UAC : São dois tokens. Quando uma tarefa administrativa é necessária, os tokens precisam ser invertidos para aquele processo.

O que deixa de ocorrer é o pedido de elevação ao usuário, a elevação - que é a inversão dos tokens - continua acontecendo só que de forma transparente.

Então voltamos a pergunta : Como o Windows 7 sabe se deve fazer a elevação de forma transparente ou não ?

As API's (funções do sistema) responsáveis pela elevação podem ser chamadas de partes do próprio SO ou de softwares de terceiros. Então quando chamadas de partes do próprio SO estas API's simplesmente não fazem o pedido de elevação e quando chamadas por softwares de terceiros fazem o pedido.

Só que não é tão simples :

• Não é todo o sistema operacional que pode rodar elevado. Notepad, por exemplo, não pode. Apenas algumas partes do sistema operacional podem pedir a elevação de forma transparente
• Manter uma lista das partes do sistema operacional que podem pedir elevação de forma transpartente seria algo extremamente ruim para a manutenção do SO, um típico problema de desenvolvimento conhecido pelos programadores.
• Além disso, como distinguir o que é parte do próprio SO e o que é software de 3os ?

Para resolver estes problemas, a Microsoft criou uma chave de manifesto a mais e passou a inclui-la nas aplicações que irão utilizar a elevação transparente :

   1: <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"> 

   2:     <autoElevate>true</autoElevate> 

   3: </asmv3:windowsSettings>

Apenas para recordar, manifesto é um documento XML incorporado no assembly principal da aplicação e que determina algumas características de sua execução. A partir da versão 2008 do Visual Studio a configuração de manifestos passou a ser parte das propriedades de um projeto.

O manifesto, claro, não é suficiente, pois só com ele qualquer aplicação poderia incluir o mesmo manifesto e facilmente tomar proveito da elevação transparente. Por causa disso, além do manifesto as partes do SO que irão utilizar elevação automática são assinadas pela Microsoft.

Assim sendo, ambas as coisas são checadas : primeiramente o manifesto, que funciona como um pedido para ter a elevação automática, em seguida a assinatura, que funciona como uma permissão para que a elevação automática seja concedida.

Desta forma, nenhuma aplicação de terceiros conseguiria a elevação, por não ter a assinatura, certo ?

Errado.

A especialidade dos códigos maliciosos é justamente conseguir se "infiltrar" em aplicações legitimas e fazer com que atuem contra o usuário. Até o momento, duas formas de fazer isso contra o UAC foram identificadas :

Simplesmente pedir : Algumas aplicações possuem mecanismos para interagir com outras. Addins, por exemplo. Um exemplo demonstrado no Windows 7 é o caso do rundll32.exe. Trata-se de uma aplicação disparadora para muitas "partes internas" do SO, como configurações do painel de controle, por exemplo.

O rundll32.exe é um exemplo já demonstrado da possibilidade de disparar uma aplicação com altos privilégios sem que o usuário perceba. Veja a demonstração, com código disponível

Code Injection : Trata-se de uma técnica de injetar-se código dentro de um processo em execução, fazendo com que o código rode com os privilégios do processo em questão.

Existem API's do sistema operacional que permitem que a injeção de código seja feita naturalmente, em especial API's para depuração. Utilizando-se destas API's pode-se injetar código em outros processos em execução.

Claro que não se pode depurar um processo que esteja rodando em nível de segurança alto. Porém existem vários processos no sistema operacional que rodam com nível de privilégio normal, mas possuem a permissão para rodar em nível de privilégio alto (possuem o manifesto e a assinatura).

Por rodarem em segurança normal, podem ser depurados e consequentemente sofrerem code injection, que permite que qualquer aplicação eleve-se sem o conhecimento do usuário.

Veja uma demonstração do code injection no Windows 7

Veja a lista de aplicações em white-list e sujeitas a code-injection

A posição da Microsoft

Em resumo, a posição da Microsoft é que o primeiro bug será corrigido na release candidate, mas nada foi falado sobre o 2o. Tendo a Microsoft já disponibilizado uma lista de alterações entre a beta e a RC, o 2o bug ficou sem correção.

É interessante, porém, analisarmos as informações que tem sido trocadas com a Microsoft sobre estas falhas.

Etapa 1 : Recusa em corrigir o problema

A recusa inicial pode ser lida no blog do E7 (time de engenharia do Windows 7)

Justificativa : Não é uma falha, porque para ser uma falha o malware precisa de uma forma para entrar na máquina e as proteções com relação a entrada na máquina estão altas. Atualmente um malware só consegue entrar se for executado pelo usuário e o usuário não deveria executar código não confiável.

De tão absurda essa afirmativa fica até mesmo parecendo piada. Vamos ver o número de absurdos que conseguimos encontrar nesta única afirmação :

1) Não é porque temos vários níveis de segurança que devemos simplesmente aceitar uma falha em um confiando em que os outros resolverão o problema.

2) Basta o uso de engenharia social para se conseguir burlar todo o primeiro nível de segurança. Prometa ao usuário que o programa que ele está executando é "X" e ele irá executar. Quando o usuário descobrir que o programa fez "Y" e não "X", já será tarde demais.

3) O UAC como nível adicional de proteção facilita a obtenção de aplicações na web.

Por várias vezes já peguei softwares de origens não totalmente confiáveis na internet e agradeci ao santo UAC pelo nível de segurança adicional : Posso executar o software sem muito problema, apenas ficando atento aos alertas do UAC - se a aplicação tentar fazer algo indevido, o UAC avisa e posso recusar. Com o bug descrito neste texto, perdemos este nível de proteção adicional.

4) O UAC é uma proteção adicional contra vírus. Antes do Windows Vista periodicamente precisava fazer uma limpeza e sempre encontrava centenas de virus na máquina. Desde que passei a utilizar o windows vista, nunca mais peguei virus algum.

Curiosidade : Já fui desafiado a executar alguns malwares para ver se seriam barrados pelas proteções do vista - foram. Executei explicitamente aplicações malware e o UAC barrou todas.

O bug descrito neste texto nos faz perder este nível de segurança.

5) Código confiável normalmente é código assinado, porém muitos grandes fabricantes ainda não pegaram a prática de assinar suas aplicações. Frequentemente encontro software de fabricantes conhecidos que aparecem como não assinados, por isso deixar toda a segurança depender da decisão do usuário de executar algo ou não é uma má idéia. O UAC permite que o usuário execute e depois, se for avisado que a aplicação está exigindo permissões que não deveria, recuse a elevação.

Justificativa 2 : Não é uma vulnerabilidade.

A Microsoft se apegou a definições rígidas para afirmar que o problema do UAC não é uma vulnerabilidade pois depende do usuário baixar e executar o código para que este possa invadir a máquina.

Definições burocráticas não deveriam ser utilizadas desta forma : O usuário VAI baixar código, VAI executa-lo e deveria caber ao UAC servir como última barreira contra um código malicioso quando isso ocorrer, porém o bug aqui descrito anula esta última barreira - a máquina fica desprotegida contra as aplicações que o usuário executar.

Resultado : Não importam definições burocráticas, da forma como está o Windows 7 vai ser suscetível a invasões que o Windows Vista não era, portanto vale o título deste post - O Windows 7 é menos seguro que o Vista

Justificativa 3 : UAC não é uma barreira de segurança, malwares inteligentes evitam o UAC.

Ok, e eu sou o coelhinho da páscoa.

A única forma de evitar o UAC é não fazendo nada que exija privilégios de administrador, o que consequentemente cria um limite muito consideravel em relação ao dano que um malware é capaz de fazer.

Se o UAC nos protege contra malwares que causem demasiado mal para o sistema, então é uma barreira de segurança, o resto é tentativa de distorção do óbvio.

Justificativa 4 : O usuário não deveria utilizar uma conta de administrador

O UAC tornou possível que o usuário utilize uma conta de administrador e ao mesmo tempo esteja rodando como usuário comum, sendo alertado a cada vez que os privilégios de administrador forem necessários - para desta forma saber se algo indevido está acontecendo.

Resultado

Após o "não" imposto nestas primeiras comunicações, a Microsoft sofreu pressão de todos os lados para corrigir o problema. Sofreu pressão tanto daqueles que entendem o problema como de pessoas que não conseguiram ainda compreender o funcionamento o UAC, mas viram um problema.

Como resultado, no mesmo dia, 5 de fevereiro, uma nova mensagem foi publicada no blog E7 mudando a forma de expor a questão

Etapa 2 : Vamos corrigir "x" e "y"

Em um 2o momento, no mesmo dia 5 de fevereiro, a Microsoft anunciou que devido aos intensos pedidos da comunidade iria corrigir duas características do UAC.

A Microsoft resolveu corrigir o 1o bug - O fato de que mudar o nível do UAC e até mesmo desliga-lo não exigia uma elevação de permissões - mas deixou o 2o completamente esquecido.

O problema é que nada foi feito com relação ao 2o bug descrito neste texto - que permite que uma aplicação eleve suas permissões através do uso de code injection em aplicações que encontram-se na white-list.

De nada adiante ter resolvido um grande problema se outro tão grande quanto foi mantido. Consequentemente, o nível de configuração default do UAC no 7 - "Avise-me apenas se programas tentarem fazer mudanças no computador" - é totalmente inútil, pois qualquer malware pode burlar este nível, elevando-se através das aplicações em white-list e fazendo um grande estrago na máquina.

Existem soluções técnicas para o problema - uma simples verificação de call stack, por exemplo. Porém a Microsoft não deu nenhuma palavra adicional sobre o assunto.

Resultado

A estratégia de comunicação da Microsoft foi extremamente inteligente : Recusando a correção, a Microsoft sofria ataques de todas as direções, mesmo daqueles que não faziam a menor idéia do que isso significava.

A partir do momento que pegou um item (na verdade 2, mas não fez diferença) do que era pedido e corrigiu, passou a usar um discurso de "Viu ? Ouvimos vocês e atendemos a seus pedidos!" e consequentemente passou a ser elogiada por todas as direções.

As poucas pessoas que perceberam - e se decepcionaram - com o drama de ver um problema deste porte chegando na versão Release Candidate, passaram a ser alvo de todos aqueles que se interessam no assunto mas ainda não entenderam o UAC. Muitos passaram a comentar nos blogs ou escrever e-mails dizendo : "Você está atrasado, a MS corrigiu isso no inicio do mês!" - sem terem o conhecimento de que trata-se de um bug totalmente diferente.

Conclusão

A melhor conclusão pode ser usar um pouco de imaginação literária para identificar o que a MS está tentando nos dizer e não pode :

"Criei um sistema super seguro - o Vista - e vocês reclamaram que tinha janelinha de confirmação demais.

É assim ? Então tirei as janelinhas de confirmação. A segurança foi embora junto, é consequencia. Tome Windows 7!"

Aqueles que realmente entendem o UAC irão - decepcionados - ter que alterar a configuração default para o nível máximo de UAC sempre que instalarem o Windows 7.

Os que não entendem o UAC - a grande maioria - terão sido atendidos no sentido de terem menos janelas de confirmação. Terão menor segurança que o Vista - sim, terão - mas afinal, muitos nem estavam utilizando o Vista, por não gostarem das confirmações, ou desligavam o UAC, então acaba não fazendo diferença.

Se nada mudar (e não parece que vai), o Windows 7 é, sim, menos seguro que o Vista. Loge de estar errado, é uma jogada inteligentissima de mercado. Apenas é decepcionante para amantes de tecnologia saber que uma tecnologia (UAC) teve que regredir tecnicamente para atender aos pedidos dos usuários.

Amantes de tecnologia, como eu, ficam se perguntando se realmente não haveria solução simples para manter o melhor dos dois mundos sem o bug - tal como uma simples checagem de call stack. Porém a Microsoft não vai responder isso.

Por que será que regredir uma tecnologia a pedido do público me lembra Idiocracy ?