Segurança na Microsoft

Dica de Livro: The Big Switch: Rewiring the World, From Edison to Google

A eletricidade mudou o mundo no século XIX. Nas indústrias os motores elétricos substituíram o trabalho manual e as intrincadas máquinas a vapor, e nas ruas as lâmpadas elétricas começaram a substituir nas as lâmpadas a gás e querosene. Nesta época a energia era gerada de forma privada por cada empresa, e  companhias como a Edison General Electric Company (mais tarde simplesmente General Electric) surgiram para atender a um nascente mercado de geradores de energia. A Edison vendia os geradores elétricos e fornecia serviços de consultoria para serem instalados em cada indústria.

A verdadeira revolução no entanto viria um pouco mais tarde. Um dos executivos da Edison, Samuel Insull, fundou uma nova empresa que vendia para os consumidores não os equipamentos, mas a própria energia elétrica. Insull comprou uma quantidade até então nunca vista de geradores e criou em Chicago a primeira rede elétrica, oferecendo energia para as empresas cobrando pelo consumo de cada uma. Insull mais tarde explorou novas formas de tarifação para explorar ao máximo da sua infraestrutura, cobrando menos pela energia consumido de madrugada e criando sobretaxas nas horas de pico.

A energia gerada em casa não tinha como competir com o ganho de escala oferecido pela rede elétrica. Mais ainda, a rede elétrica permitiu que a eletricidade chegasse aos domícilios, viabilizando o aparecimento de pequenos equipamentos elétricos de uso caseiro, chamados eletrodomésticos.Foi a rede elétrica, e não necessariamente a energia, quem realmente mudou a vida das pessoas.

Em The Big Switch, Nicholas Carr usa esta história para fazer um persuasivo paralelo com o que a Internet está fazendo com a tecnologia da informação. Segundo Carr, a Internet permite que mega datacenters como os da Microsoft, Google e Amazon possam fornecer serviços de TI de forma mais barata e confiável que os serviços oferecidos in-house. Tecnologias como virtualização fazem com que toda uma infraestrutura de TI possam ser montada sem custo de aquisição, tarifada somente pelo consumo, e entregue ao usuário qualquer lugar. Os servidores vão estar na "nuvem" (cloud) e não mais no CPD.

Os sintomas desta mudança já podem ser vistos. A Sun Microsystems está acabando com os seus CPDs. O Twitter (aquele irritante serviço de blog instantâneo) e vários outros serviços online na verdade não tem um único servidor, usando a infraestrutura fornecida pela Amazon. Um relatório do Radicati Group estima que em 2011 25% dos clientes do Microsoft Exchange vão ter suas caixas-postais rodando em servidores da Microsoft, em datacenters da Microsoft. Não é a tôa que, assim como Insull em Chicago, Google e Microsoft estão construindo datacenters com massivo poder de processamento. O livro traz uma explicação coerente e clara do que está por trás de tudo isto, e para onde estamos (rapidamente) indo.

Bem, e o que isto tem a ver com segurança? Tudo. Para começar, a maioria das atuais arquiteturas de segurança é baseado em proteções de perímetro e de rede - firewalls, sistemas de detecção de intrusão, etc. Como fica isto agora com se os dados e os serviços na cloud? Como proteger dados que vão estar sob custódia de um fornecedor? Como garantir a disponibilidade destes serviços (uma pergunta muito pertinente devido à recente indisponibilidade da Internet em São Paulo)? Como proteger os computadores e dispositivos móveis dos usuários, agora plugados diretamente na Internet?

Mesmo não sendo um livro sobre segurança, The Big Switch descreve o pano de fundo para todos estes desafios que vamos enfrentar nos próximos anos. O livro ainda aborda outras questões interessantes, como por exemplo se o fácil acesso a informação está nos emburrecendo, e como por trás de uma aparente liberdade a Internet pode permitir um controle muito maior das nossas vidas. Altamente recomendado.

Processo SDL em Detalhes

A Microsoft acaba de divulgar para download a documentação do seu processo de desenvolvimento seguro (Secure Development Lifecycle ou SDL). Este é basicamente o mesmo documento que é usado internamente pelos times de produto da Microsoft (apenas "sanitizado" para remover referências para sites internos, etc.), e descreve em detalhes cada uma das 11 fases do processo, com os requisitos de segurança e privacidade envolvidos em cada fase e referências para mais informações.

As informações mais interessantes talvez estejam nos anexos, onde estão descritos vários critérios técnicos usados no desenvolvimento, como os parâmetros de compilação, linkagem e análise de código fonte utilizados e a política em relação a interação com firewalls. Lá estão também o questionário utilizado na avaliação de privacidade e exemplos de bug bar e security plan usados durante o processo.

Esta é a versão 3.2 do processo, que é versionado a cada seis meses. O documento está em inglês e no formato ISO 29500 (Open XML) usado pelo Office 2007. Para abrir o documento em versões anteriores do Microsoft Office é necessário instalar o Office Compatibility Pack (download gratuito).

Vulnerabilidade Cross-Plataforma no Flash

Uma das principais verdades sobre segurança da informação é que ela está sempre mudando. Os ataques de hoje não são os mesmos de ontem, e serão totalmente diferentes amanhã. Na Internet nós tivemos a época dos vírus de macro (1990s), depois os virus de e-mail como o Melissa (1999), worms como o Code Red (2001) e Blaster (2003), e então páginas Web maliciosas explorando vulnerabilidades em browsers como o Mpack (2007).

Cada uma destas ameaças foi superada com o desenvolvimento de defesas que, se não eliminaram totalmente as vulnerabilidades que permitiam estes ataques, pelo menos tornaram-os difícil o suficiente para fazer com que os atacantes mudassem de tática. Por exemplo, mudanças no Office que exigiam a assinatura digital das macros acabaram com este tipo de vírus. O bloqueio de anexos executáveis no Outlook e Outlook Express eliminou vírus como o Melissa. O Windows Firewall habilitado por default ajudou a diminuir a ameaça de worms como o Blaster.

Provavelmente é cedo para dizer que melhorias nas práticas de desenvolvimento do IE e do Firefox irão diminuir o número de páginas Web explorando vulnerabilidades nestes browsers. Exploits para ambos os browsers continuam aparecendo e eles ainda são alvos muito tentadores para atacantes. Mas nós estamos vendo cada vez mais sinais de que os alvos dos ataques estão mudando para outros softwares, tão ou mais populares que estes browsers, que ainda não tinham sofrido um escrutínio tão grande e assim são uma fonte relativamente inexplorada e fértil de bugs de segurança. Colabora ainda o fato destes softwares terem mecanismos de atualização ainda primitivos, ou em alguns casos simplesmente nenhum tipo de atualização.

Por exemplo, o MPack já utilizava entre o seu arsenal de exploits uma vulnerabilidade do WinZip. Recentemente, no desafio "Pwn to Own" onde prêmios em dinheiro eram pagos para quem conseguisse invadir alguns sistemas, um laptop com Windows Vista foi comprometido usando uma vulnerabilidade não no Windows ou no IE, mas no Adobe Flash.

Agora uma nova vulnerabilidade potencialmente devastadora foi descoberta no Flash, e assim como a outra com a capacidade de comprometer sistemas com rodando qualquer sistema operacional, contanto que tenham o Flash instalado. Com a "vantagem" adicional que no Windows exatamente o mesmo exploit pode ser usado tanto para IE quanto para Firefox - os dois usam o mesmo endereço base e um único exploit funcionaria em ambos os navegadores.

Esta vulnerabilidade foi descoberta por Mark Dowd da IBM (enquanto uma parte da IBM fala bobagem sobre documentos XML, outra faz pesquisa de segurança de alta qualidade), que descreveu o ataque em detalhes em um paper excepcional. O paper ainda descreve como o ataque ultrapassa a proteção do ASLR no Vista - a Adobe não compilou o Flash com ASLR! Obrigado Adobe.

A lição para o futuro é que a segurança de um sistema não depende só do sistema operacional e do navegador, e sim na verdade de todas as aplicações instaladas no sistema. Organizações e indivíduos devem avaliar a segurança de cada software antes de fazer a instalação, e se assegurar que o seu processo de gerência de patches contempla todos estes softwares. Um ponto que o Augusto já tinha levantado por sinal, mas que diante deste novo bug vale a pena reforçar.

RSA Conference 2008

Não, infelizmente este ano eu não estou na RSA Conference em San Francisco (por algum motivo eu só vou nos anos em que ela acontece em San Jose!), mas a Microsoft está presente em peso e com um blog especial dedicado ao evento. No primeiro post já uma ótima discussão sobre o isolamento entre máquinas virtuais.

Boa Notícia: Aprovação do Padrão Open XML na ISO

A ISO divulgou hoje que o padrão aberto de documentos Office Open XML é agora um padrão internacional mantido pela ISO, com o número ISO/IEC 29500. Após um processo de votação onde participaram 87 países, o padrão foi aprovado com ampla maioria de 75% dos votos dos países "P" (participantes) e 86% dos votos totais, não contando as abstenções.

Isto significa que o padrão de documentos usado pelo software de escritório mais popular do mundo (o Microsoft Office) está agora sobre o controle da ISO. É o final de um processo que começou em 2005, quando a Microsoft enviou para a ECMA o primeiro draft da especificação, e que onde mais de mil comentários para melhoria foram examinados só dentro da ISO. Poucos padrões foram tão rigorosamente examinados como o ISO 29500, e isto se reflete na qualidade do padrão agora finalmente aprovado.

A padronização na ISO é uma tremenda vitória para os usuários, que tem a garantia que os seus documentos podem ser abertos e processados de acordo com uma especificação pública, aberta e sob controle internacional. É uma vitória em especial dos usuários que necessitam assinar digitalmente e/ou criar fluxos de documentos, já que o formato Open XML suporta assinaturas digitais compatíveis com a ICP-Brasil e schemas customizados, recursos que não existem por exemplo em outros formatos com o ODF. Os usuários continuam tendo o direito de escolher o formato mais apropriado para os seus documentos, direito que queria ser cassado pela IBM (mais sobre isso a frente).

Mais significativamente, o Open XML "liberta" os usuários destes documentos de ter que usar Microsoft Office, permitindo que esses documentos possam ser criados e consumidos livremente (e facilmente) por outras aplicações. Mas que outras aplicações? Eu dividiria em dois grupos:

■ Aplicações corporativas, desenvolvida em geral para organizar fluxos de documentos. Por exemplo, uma aplicação de reembolso de despesas pode agora receber como entrada uma planilha e extrair os seus dados para consumo, sem precisar ter o Microsoft Excel instalado. Ou um tribunal pode receber uma petição, ou gerar um acórdão, sem precisar comprar e instalar o Word no servidor. E sem claro precisar estar rodando sobre Windows.

(Por exemplo, está disponível aqui uma aplicação Web JSP, rodando com Linux e MySQL, que gera documentos Open XML).

■ Suítes de escritório, inclusive as de código aberto como o KOffice e o OpenOffice, quem tem agora ao seu dispor uma documentação completa, aberta e pública em que se basear para interoperar com o Microsoft Office. Estas suítes podem ainda implementar esta interoperabilidade com a garantia que podem utilizar sem risco todas as patentes envolvidas, e que qualquer mudança no padrão terá que ser aprovada pela ISO em um processo público e aberto a todos os países. Não é a toa que o OpenOffice já anunciou o suporte ao Open XML na sua versão 3.0.

Neste processo ganham também a ISO e os órgãos nacionais de padronização, como a nossa ABNT, que se consolidam como o fórum onde os padrões relevantes para a indústria de TI são discutidos e aprovados. No caso do Brasil foi impecável o trabalho da ABNT na condução do processo, e é incrível ver como eles possuem a experiência (e a paciência) para procurar o consenso mesmo entre grupos com posições radicalmente diferentes. Para nós da Microsoft Brasil foi um grande aprendizado e vamos continuar trabalhando com a ABNT no aperfeiçoamento do Open XML.

E quem perde com a aprovação da ISO 29500? Perde basicamente a IBM, que surpreendentemente liderou um lobby maciço e sem precedentes contra a aprovação deste padrão, envolvendo centenas de funcionários e lobistas. Digo "surpreendentemente" porque a IBM tem uma enorme receita com o desenvolvimento de sistemas conectados e middlewares, e seria uma das grandes beneficiárias da adoção de padrões abertos e baseados em XML para representar documentos.

A IBM entanto resolveu apostar em uma estratégia mundial - a meu ver incrivelmente míope - de tentar ressuscitar a sua moribunda linha de suítes de escritório impondo a adoção do padrão ODF no setor público. Nos planos da IBM, a obrigação de usar o formato ODF tornaria irrelevante uma série de funcionalidades presentes no Microsoft Office que este formato não suporta (como assinaturas digitais), permitindo que um produto mais limitado como o Symphony pudesse competir no mercado.

Esta estratégia se apoiava em duas pernas: (1) o ODF deveria ser o único formato para documentos de escritório aprovado na ISO, e (2) legislação seria criada para forçar o uso de ODF pelos diversos governos. Durante os três últimos anos a IBM trabalho pesadamente para garantir estes dois pontos, e por isso era para ela vital que a ISO não aprovasse o padrão Open XML.

Nunca houve antes uma campanha tão ferrenha contra a elaboração de um padrão internacional. A ordem da IBM era clara: o Open XML não poderia ser aprovado de jeito nenhum. Não importava quais mudanças fossem feitas, o voto tinha que ser não. O lobby sem limites levou a algumas situações bizarras, como por exemplo um voto inicialmente submetido pelo Quênia ter sido escrito por um funcionário alemão da IBM - o sujeito enviou o voto em PDF e aparentemente se esqueceu de tirar o próprio nome dos metadados do arquivo! Ou a manobra no final para cassar os votos de todos os países de status O (observador) dados na reunião em Genebra, tentando anular os votos inclusive do Brasil nesta reunião.

Após o sucesso da reunião final em Genebra e a notícia que os países estavam votando em massa pela aprovação do padrão, o lobby contra a aprovação do Open XML começou a fazer acusações mirabolantes de fraude e corrupção contra vários órgãos nacionais de normatização que votaram a favor, como Noruega (!), Alemanha (!!) e até mesmo o prestigioso British Standards Institute (BSI) inglês (!!!). A IBM Brasil chegou até mesmo ao ponto de acusar a Microsoft de ter "estuprado" a ISO.

Tudo isso é muito lamentável, e é reconfortante saber que a ISO e os órgãos nacionais de normatização tomaram a decisão sensata mesmo em meio a toda esta histeria.

Se você usa o Office 2003, Office XP ou Office 2000, pode já começar a usar o formato Open XML instalando gratuitamente o Open XML Compatibility Pack.

Para assinar e visualizar assinaturas digitais em documentos Open XML, use o Assinador Digital open source desenvolvido pelo time do LTIA/UNESP.

Você pode começar a testar o OpenOffice 3.0 com suporte a documentos Open XML obtendo a versão M3.

Anonimato e Responsabilidade

Este argumento vem de um artigo relativamente antigo do Bruce Schneier. O verdadeiro problema na Internet não é o anonimato e sim falta de responsabilização (talvez a melhor tradução para o original accountability). Se é possível responsabilizar alguém por uma ação, não importa se nome dela é "João" ou "Helena".  Da mesma forma, pouco me adianta saber o nome da pessoa se não é possível atribuir responsabilidade por algum ato.

Nós no entanto estamos condicionados a sempre associar uma coisa a outra. Um exemplo está na nossa própria Constituição, que no seu artigo mais importante declara ser "livre a manifestação do pensamento, sendo vedado o anonimato". Para mim está claro que a intenção dos nossos constituintes foi garantir a liberdade de expressão, mas ao mesmo tempo deixando claro que cada um é responsável pelo que expressa. Como não conheciam nenhuma forma de responsabilizar alguém por um discurso anônimo, foi então suprimido o anonimato. Mas não é ele o problema.

Outro bom exemplo está na nossa infraestrutura de certificados digitais, a ICP-Brasil. A ICP-Brasil foi criada em grande parte para permitir que documentos e transações possam ser feitos eletronicamente de uma forma que permita a responsabilização das partes. Ela fornece o que no jargão técnico se chama não-repúdio - a impossibilidade de uma ou mais partes refutarem uma transação ou documento em que teriam participado. Isto torna viável a migração de diversos processos e serviços para um formato eletrônico, e para mim a ICP-Brasil fornece um valor inestimável para o país.

Só que a ICP-Brasil, assim com a nossa Constituição, estabelece esta responsabilidade sacrificando o anonimato. Um certificado digital ICP-Brasil contém entre outras coisas o nome completo, data de nascimento, o número de CPF, o título de eleitor e o número de seguridade social do cidadão. Estas informações são sempre apresentadas todas para a outra parte quando você utiliza o seu certificado para assinar um documento ou se autenticar em um site Web. Enviou um e-mail assinado digitalmente com um certificado ICP-Brasil? Todos estes dados vão junto com a mensagem. Entrou em um site Web e uso o seu certificado ICP-Brasil para se logar? Todos estes dados são enviados para o dono do site.

Ou seja, a ICP-Brasil atende perfeitamente os cenários onde seja necessário identificar precisamente cada uma das partes, ou quando isto seja pelo menos desejável. Ninguém teria o menor problema em assinar uma escritura de um imóvel ou entregar a sua declaração do imposto de renda, que além de tudo já contém no seu próprio corpo todas as informações que constam no certificado digital. Mas existe uma outra enorme variedade de cenários onde um determinado nível de privacidade é desejável que não são podem ser atendidas hoje pela ICP-Brasil.

Em alguns casos somente um conjunto parcial de atributos devem ser conhecidos pela outra parte.  Por exemplo, ao postar um comentário no MeioBit eu preciso fornecer apenas o meu nome - o MeioBit não está interessado no meu número de CPF e de eleitor (e nem eu interessado em fornecer a eles!).  Para entrar em um site pornô um usuário pode querer somente fornecer a data de nascimento, ou mesmo somente o ano, sem enviar por motivos óbvios o seu nome nem nenhum outro dado pessoal.

Existem ainda situações onde o usuário pode não querer enviar nenhuma informação para a outra parte, e ainda assim poder demonstrar que é o autor da transação. Um exemplo são as redações e provas práticas apresentadas em um concurso público. O documento deve ser anônimo para garantir a imparcialidade dos avaliadores, mas ao mesmo tempo precisa ter a sua origem e integridade determinada sem qualquer margem para dúvidas.

No limite estão os cenários onde a identidade do usuário que realizou a transação não deve ser conhecida nem mesmo por quem emitiu a credencial. Um exemplo é o do voto eletrônico, onde ninguém deve ter a capacidade de descobrir a identidade do autor do voto, mas ao mesmo tempo o sistema tem que garantir que o voto está íntegro (i.e. não foi alterado), teve como origem uma pessoa válida, e ainda que cada pessoa somente submeteu um único voto.

Nos próximos anos a Internet irá necessitar de identidades confiáveis para atender a todos estes cenários. A pergunta que vai estar diante da ICP-Brasil é se ela vai querer ser o fornecedor destas identidades, e começar a discutir desde já temas relacionados a privacidade (como o uso de pseudônimos, identidades parciais e o controle na divulgação de atributos), ou se a ICP-Brasil vai se contentar ficar apenas em um nicho das aplicações, deixando todo o resto para outros sistemas de identidade.

Release Candidate do Hyper-V Disponível

A mais recente versão de teste do software de virtualização da Microsoft está agora disponível para download. Esta versão será provavelmente a última antes do lançamento e contém já todos os recursos que estarão presentes na versão final. As instruções para instalação estão aqui e requerem uma versão 64-bits (x64) do Windows Server 2008.

Uma boa leitura sobre o hypervisors em geral e Hyper-V em particular está na primeira edição da revista online Antebellum, publicada e distribuida gratuitamente pelo capítulo brasileiro da ISSA. Neste primeiro número - que aliás ficou muito bom - o Fernando Fonseca explica em um artigo como funciona o modelo de virtualização do Hyper-V e cobre temas como paravirtualização e segurança.

OpenOffice 3.0 Suporta o Formato Open XML

Quem acompanha o processo de padronização do Open XML na ISO certamente já escutou a IBM (e os lobistas pagos por ela) argumentarem veementemente que somente a Microsoft teria a capacidade de implementar este padrão. Bem, depois de várias outras empresas como o Google, a Adobe e a Apple, agora também o projeto OpenOffice anunciou que irá suportar o padrão OpenXML.

Como a IBM me assegurou que isso era impossível - e eu tendo a acreditar nas pessoas - resolvi eu mesmo tirar a prova. Peguei no mirror do projeto a versão M3 do Open Office 3.0, mais recente versão de teste disponível. Criei um texto com características típicas de um documento Office, como formatação de fonte e uso de tabelas, e salvei no formato Open XML (DOCX):

Tentei então abrir o documento DOCX no OpenOffice 3.0:

Parece bastante bom! E ainda estamos em uma versão pré-beta, o que indica que o suporte na versão final deve ser ainda melhor. Parabéns ao projeto OpenOffice por ter feito o "impossível".

Falando nisso, como anda a manobra da IBM para anular os votos do Brasil na reunião da ISO? Alguém sabe?

Novas Aquisições: Kidaro, Komoku, Credentica

Enquanto a novela da aquisição do Yahoo continua, sem muita reprecussão Microsoft comprou três pequenas empresas na área de segurança, todas elas fornecedoras de tecnologias que serão vitais nos próximos produtos da Microsoft:

■ A israelense Kidaro fornece uma plataforma para criar e gerenciar máquinas desktop virtualizadas. O Kidaro Desktop Virtualization Platform permite que empresas criem máquinas virtuais contendo todo o desktop do usuário (ou apenas aplicações específicas - as chamadas virtual appliances), incluindo os dados, e provisionem estas máquinas para serem utilizadas os seus usuários.

Para usar o seu desktop ou uma aplicação virtualizada, o usuário tem apenas que se conectar na rede, autenticar no Active Directory e iniciar o trabalho. Ou seja, você trabalha de onde você estiver e no computador que você quiser. E o melhor: ao invés de usar a rede, o Kidaro permite que a sua máquina virtual resida em um pendrive USB, que o usuário carrega e usa também onde quiser.

O Kidaro ainda encripta todas as máquinas virtuais e permite que o administrador defina políticas para evitar vazamentos de dados, incuindo que aplicações podem ser executadas, acesso a dispositivos, cut and paste, etc. Também permite que uma parte do desktop seja considerada imutável, como arquivos de sistema e aplicações, sem que o usuário (ou mais provavelmente um malware) tenha como comprometer a segurança e a estabilidade do sistema.

■ A americana Komoku é uma empresa especializada na detecção e remoção de rootkits. Entre os seus produtos estavam o Co-Pilot, uma placa PCI que monitora o comportamento do sistema e detecta anomalias e comportamento suspeitos - por hardware! Uma abordagem por software usando virtualização é descrita nesta apresentação, e dá uma boa idéia de como a Microsoft pode usar esta tecnologia.

■ Por fim, a canadense Credentica atua em um segmento relativamente novo de criptografia, chamado de zero knowledge proofs. Esta tecnologia permite que uma pessoa possa se autenticar, ou mostrar que possue um determinado atributo, sem precisar revelar nenhuma informação sobre si mesmo. Por exemplo, você pode provar que é um assinante de um site sem dizer quem você é. Ou que tem mais de 18 anos sem revelar a sua idade. Ou até mesmo que você é o mesmo usuário anônimo que uso o sistema em uma sessão anterior.

Este tipo de criptografia resolve um dos problemas associados ao uso de infraestruturas de chaves públicas (PKIs) tradicionais: o da privacidade. Por exemplo, dentro do meu certificado digital da ICP-Brasil estão informações como o meu CPF, o meu RG, o meu cadastro no INSS e o meu título de eleitor. Sempre quando eu usar este certificado para me autenticar em um site Web eu estarei enviando todas essas informações para o site, quer elas sejam relevantes (e eu queira enviá-las para o site) ou não.

Ou seja, ao usar um certificado digital você passa a ter estes sites também como custodiantes de toda esta informação pessoal. E como este site vai usar essa informação? Como (e se) ela vai ser armazenada? O usuário da ICP-Brasil passa a correr o risco destas informações serem roubadas, ou usadas indevidamente pelo próprio site. Além disso é impossível usar este certificado para se autenticar em sites Web onde se queira ter qualquer tipo de anonimato.

(Interessante ver que no modelo proposto para a identidade eletrônica alemã está sendo proposto a inclusão de um "pseudônimo" para uso nestas aplicações.)

A tecnologia da Credentica permite que um serviço possa emitir credenciais para um usuário que ele possa usar anonimamente depois. O usuário pode escolher mostrar somente um pedaço da sua credencial para um serviço, omitindo as informações que ele não julgue relevante ou que ele não queira apresentar. A tecnologia ainda permite alguns modelos de negócio interessante, como a emissão de credenciais que somente possam ser utilizadas um número determinado de vezes.

A Credentica foi alvo de uma matéria recente na Wired, que curiosamente pergunta se alguém realmente estaria interessado nesta tecnologia (Bruce Schneier comentou a mesma coisa). Na verdade isto é central para a estratégia de identidade digital da Microsoft, e a tecnologia da Credentica vai ser incorporada ao Windows Communication Foundation (WCF) e no CardSpace. Para os interessados, uma descrição extensa desta tecnologia está no livro Rethinking PKI, publicado pela MIT Press e disponível gratuitamente para download. Um bom background matemático é recomendado.

Open XML: IBM Agora Quer Cassar os Votos do Brasil na ISO

Não é segredo nenhum que a IBM está financiando um poderoso lobby para impedir a aprovação do padrão aberto Open XML na ISO, como parte da sua estratégia de forçar via legislação o uso do padrão ODF pelos governos. Este esforço já produziu algumas cenas "curiosas", como o fato do documento de comentários do Quênia (bastante negativo em relação ao Open XML) ter sido escrito por um funcionário - alemão - da IBM! Esqueceram de mudar os metadados do documento PDF...

Mas o mais recente lance da IBM é ainda mais curioso. Um rápido prêambulo antes para entendermos o contexto do que está acontecendo.  

Há duas semanas aconteceu em Genebra o BRM (Ballot Resollution Meeting), a reunião da ISO onde os países membros do comitê JTC1 decidiram qual seria a versão final do padrão Open XML, a ser aprovado (ou não) posteriormente por estes países. Nesta reunião são discutidos os comentários técnicos apresentados previamente por cada país, e apresentada a resposta sugerida pelo editor do documento. Depois, por consenso ou votação, é aprovada a resolução dada para aquele comentário, aprovando a sugestão do editor ou outra sugestão dada pelos países.

O resultado do processo é um padrão mais aperfeiçoado e mais perto do consenso dos países, que é então submetido a uma votação em até 30 dias após o BRM. É importante notar que a votação sobre se o padrão vai ser aprovado acontece só agora nestes 30 dias - durante o BRM é apenas aprovado qual será a redação final que será votada pelos países.

O comitê JTC1 tem países que são membros "P" (participantes) e países que são membros "O" (observadores). Isto é uma escolha de cada país, e que traz um impacto direto em várias etadas do processo de construção da norma. O Brasil é um membro "O" do JTC1, por escolha da ABNT.

O BRM no entanto não faz esta distinção, porque não está sendo votada a aprovação da norma e sim a redação que irá a votação. Neste caso, no início da reunião, o convenor responsável por conduzir o BRM consultou a ITTF - grupo que cuida do dia a dia de funcionamento do JTC1 - e considerou que tanto os membros "P" quanto os membros "O" poderiam votar no BRM. Isto foi aprovado por todos os participantes, e foi uma ótima decisão para o Brasil, que pôde participar e votar na definição do texto final.

De acordo com todos os relatos a delegação brasileira foi uma das mais ativas, e é inegável o enorme esforço feito por todos os seus membros. Meus parabéns a eles.

A surpresa veio no final da reunião. Após o texto final ser aprovado, contendo a grande maioria das recomendações do editor, a IBM protestou alegando que as regras de votação estavam erradas. Segundo a IBM, os países "O" - entre eles Chile, Grécia, Polônia, México, Israel e Brasil - não deveriam ter direito a voto. As suas opiniões deveriam ser suprimidas e todos os votos precisariam ser recontados.

Tudo bem, eu acho que a IBM tem todo o direito que querer melar o BRM "no tapetão". Mas que fica feio, fica. Primeiro porque as regras estavam acordadas entre todos os países participantes, inclusive o Brasil, e a IBM - que tinha vários representantes na reunião - ficou quietinha até final, levantando este ponto somente quando ficou claro que a reunião tinha sido bem sucedida.

Segundo, e mais importante, fica feio porque a IBM trata assim o Brasil e a ABNT com escárnio. A IBM é membro participante da comissão CE-21 da ABNT, que estuda e define a posição do Brasil sobre o Open XML junto a ISO, e participou de todo o processo. Funcionários da IBM participaram das reuniões, definiram os comentários do Brasil, decidiram como o Brasil iria votar, indicaram os enviados do Brasil para o BRM. Em nenhum momento neste processo a IBM se manifestou dizendo que o Brasil não deveria ter direito a voto, ou que deveria mudar o seu status para "P". Preferiu esperar a reunião acabar para vir agora a público e querer jogar fora todo o trabalho da comissão.

O pior de tudo é que a manobra provavelmente não vai mudar nada - a ITTF foi bem clara sobre qual seria o procedimento e é improvável que o resultado do BRM seja modificado. Os votos do Brasil vão ser mantidos. Mas a IBM deve algumas explicações na ABNT.

[Para quem tem interesse, o FAQ oficial sobre a reunião está postado em http://www.itscj.ipsj.or.jp/sc34/open/0932.htm, e é o melhor documento para entender o processo e o que aconteceu. Os documentos oficiais da reunião estão linkados em http://www.adjb.net/index.php?entry=entry080306-082306].

Novos Recursos de Segurança do Internet Explorer 8

A Microsoft divulgou ontem publicamente o Beta 1 do Internet Explorer 8 (baixe ele aqui). Esta é uma versão de testes ainda bastante preliminar, e o seu principal objetivo é permitir que desenvolvedores possam já testá-lo com os seus sites e apontar problemas na visualização de páginas. Por isso muito da divulgação trata da conformidade com o teste ACID2, os test cases de CSS, e outros recursos do tipo.

Mas esta versão preliminar já permite ver alguns dos novos recursos de segurança implementados pelo IE8. A primeira diferença está logo na barra de endereços - o domain highlighting:

O IE8 deixa apenas o nome do domínio sendo acessado em iluminação normal, colocando o resto da URL em tom acinzentado. Isto permite que o usuário veja com mais clareza o domínio que ele está realmente acessando, tornando mais difícil para alguns sites maliciosos iludir o usuário a pensar que estão em outro domínio.

Outro novo recurso do IE8 é a restrição do uso de controles ActiveX para sites ou domínios específicos. Nas versões anteriores do Internet Explorer, quando um controle Active X era instalado por um site ele ficava automaticamente disponível para ser executado por qualquer outro site. Isto é ótimo por exemplo para controles genéricos como o Flash, que é instalado pelo site da Adobe e depois pode ser usado em todos os sites.

Mas em alguns casos isto não é desejável, e pode se tornar até um risco de segurança. Por exemplo, um banco pode escrever um controle ActiveX para validar o computador do usuário, mas certamente não vai querer que este controle seja usado também por um site malicioso para fazer a mesma validação. Para proteger contra este tipo de situação, a única solução era o desenvolvedor implementar no código do seu controle ActiveX uma proteção como o SiteLock.

O Internet Explorer 8 traz agora o recurso de restringir o uso de um controle ActiveX apenas para alguns sites específicos. Isto pode ser especificado pelo desenvolvedor e também controlado pelo usuário:

[Observação: este recurso ainda não está totalmente implementado na versão Beta 1]

Outro novo recurso é o Safety Filter. O Internet Explorer 7 continha o recurso Phishing Filter, que verificava o nome de domínio sendo acessado contra uma lista de sites que foram reportados como sendo phishing - isto é, sites maliciosos que tentavam se passar como sites legítimos e iludiam usuários a fornecer informação pessoal. O Safety Filter leva isso além e bloqueia agora também sites Web que tentam instalar malware (trojans, etc.) no computador do usuário.

Isto é uma mudança mais radical do que pode parecer em um primeiro momento. Enquanto construir uma lista de sites de phishing depende em grande parte de alguma pessoa reportar e outra validar que se trata de um site malicioso, monstar uma lista de sites que instalam malware é uma tarefa basicamente automatizada. Robôs de busca como os do Live Search podem varrer a Internet e em conjunto com engines de antivirus detectar e bloquear automaticamente as páginas consideradas perigosas.

Além disso, ao contrário do Phishing Filter do IE7, o Safety Filter verifica todas as URLs (não só paginas Web) e permite o bloqueio de downloads considerados nocivos. Se você lembrar que a maioria das fraudes de Internet aqui no Brasil são feitas a partir do download de um trojan, este recurso pode se tornar uma das principais armas para combatê-las. 

O Internet Explorer Beta 1 é ainda uma versão bem preliminar, e eu recomendo a sua instalação somente em um equipamento de teste ou máquina virtual. Para o uso diário é melhor esperar uma versão mais próxima do lançamento. Para fornecer feedback sobre esta versão, e em especial sobre os novos recursos de segurança, consulte o blog do time do IE ou deixe o seu relato no grupo de discussão.

UPDATE - E uma novidade especial para o VP: o IE 8 abre por default até seis conexões simultâneas, ao invés de duas como nas versões anteriores.

OUTRO UPDATE - O blog do time do IE descreve em mais profundidade o domain highlighting.

Editor do ODF Recomenda Aprovação do Open XML na ISO

Na semana passada ocorreu em Genebra o Ballot Resolution Meeting (BRM) da ISO sobre o padrão aberto de documentos Open XML (DIS 29500). Nesta reunião são endereçados os comentários feitos pelos órgãos nacionais de padronização, e produzido um novo texto que deve ser aprovado (ou não) em 30 dias por estes mesmos órgãos.

Eu não posso comentar sobre o que aconteceu na reunião, até mesmo porque eu não estava lá (estava a trabalho em Amsterdã, que convenhamos é um lugar muito melhor de se estar do que Genebra!), mas é interessante notar que após o BRM, o editor do padrão ODF (ISO 26300), Patrick Durusau, agora está recomendando a aprovação do Open XML como padrão ISO. No seu site ele explica as razões para ter mudado de opinião:

So, now that Microsoft is listening (something we should encourage), in an international and public
forum, what are our options?

Reject DIS 29500? The cost of rejection is that ordinary users, governments, smaller interests, all lose a
seat at the table where the next version of the Office standard is being written.

Approve an admittedly rough DIS 29500? That gives all of us a seat at the table for the next Office
standard. Granting that I wince at parts of DIS 29500, it is hard for me to argue with that rationale.

Because approval of DIS 29500 insures an effective international and public forum whose members
will be heard by Microsoft I recommend approval of DIS 29500 as an ISO standard.*

5 March 2008
Patrick Durusau

*This is a change in my prior position on DIS 29500. Different behavior has led to a different DIS
29500 and hence a different position on my part.

(grifos meus)

Isto é claro requer uma boa dose de coragem do sr. Durusau, devido ao verdadeiro linchamento promovido pelos lobistas da IBM contra qualquer um que defenda a aprovação do Open XML na ISO (a IBM tem uma estratégia clara de obrigar o uso do ODF através de leis, e uma aprovação na ISO do Open XML dificulta isto).

Por isso palmas a ele pela honestidade e pela humildade em mudar de opinião, e vamos ver o que vai acontecer na próxima votação.

Ataques contra Encriptação de Disco via Acesso a DRAM

"A Persistência da Memória", Salvador Dalí, 1931

Você já deve ter lido sobre o trabalho de pesquisadores da Universidade de Princeton sobre a possibilidade de quebrar diversos sistemas de encriptação obtendo as chaves acessando diretamente os chips de memória do sistema (o paper pode ser obtido aqui).

Nestes ataques, os pesquisadores usam uma propriedade física da memória DRAM, que mantém os dados armazenados por um período de tempo mesmo depois da energia ser cortada. Memórias DRAM são efetivamente capacitores que armazenam energia, e este período consiste no tempo em que o capacitor demora para decair ao estado de "terra". Este período depende da temperatura do ambiente, e em condições normais leva de 2,5 a 35 segundos, muito curto para um ataque na prática. No entanto, a uma temperatura de -50°C ou menor o conteúdo da memória pode se conservar por horas ou até mesmo dias, mesmo sem energia.

Isto permite que por exemplo um chip de memória possa ser retirado de um sistema em funcionamento, imediatamente congelado, e levado depois para análise em um outro PC onde todo o seu conteúdo poderá ser lido. Se a chave de encriptação estiver em memória - e normalmente está - ela vai poder ser lida e usada para decriptar o conteúdo do disco. Este ataque foi executado com sucesso contra vários sistemas de encriptação, incluindo o BitLocker presente no Windows Vista.

É um ataque interessante do ponto de vista técnico, mas na prática não significa nenhuma novidade para os usuários do BitLocker. Existem diversas formas de se obter a chave de encriptação acessando diretamente a memória, e o congelamento talvez seja uma das mais complicadas. Por exemplo,. devido a forma como a arquitetura dos PCs atuais foi desenhada, um equipamento conectado via interface Firewire, PCMCIA ou em um slot PCI pode ler diretamente a memória usando DMA e obter as chaves diretamente da memória - dispensando o nitrogênio líquido.

Em todos estes cenários o ataque tem que ser feito contra um sistema em funcionamento, já que a chave de encriptação tem que estar carregada na memória. A proteção contra este ataque, portanto, é manter o computador desligado quando o usuário não estiver ele próprio o utilizando. Isso significa desligar o equipamento quando você for sair com ele ou deixá-lo sozinho, ou usar a função de "hibernar" (hibernate) do Windows. O hibernate copia todo o conteúdo da memória para o disco (encriptado) e desliga totalmente o equipamento. Menos de um minuto depois o conteúdo da memória terá decaído e nenhum ataque poderá ser feito.

O hibernate é diferente do sleep (ou "suspender"), que na verdade apenas reduz o consumo de energia mas mantém o equipamento ligado, e portanto vulnerável a estes ataques. Portanto usuários do BitLocker nunca devem utilizar o recurso de sleep. Isto pode ser desabilitado nas novas opções de Gerenciamento de Energia incluídas nas políticas de grupo do Windows Vista. As mesmas políticas também podem programar o Vista para entrar em hibernate automaticamente depois de um determinado tempo de inatividade, protegendo assim o computador caso o usuário tenha deixado ele ligado sozinho.

Outro ponto importante é utilizar o BitLocker no chamado modo avançado, onde a proteção do TPM é completada com a inserção de um PIN ou chave USB pelo usuário. Desta forma somente com a presença do usuário o sistemapode ser ligado e a chave de encriptação carregada na memória.

Em resumo, para você ficar protegido:

1. Não use sleep, use hibernate.

2. Use BitLocker requerendo a entrada de um PIN ou uso de um token USB durante o boot.

No blog de System Integrity da Microsoft você pode ler também um post mais completo sobre esse assunto, colocado pelo Douglas Maciver do time de ataque e penetração do BitLocker.

O Primeiro Passo é Admitir que o Problema Existe

Michael Howard escreveu um post sensacional no blog do SDL que remete às estatísticas de vulnerabilidades que a Microsoft compilou após o primeiro ano do Windows Vista. Para recapitular, as estatísticas mostraram que o Windows Vista teve no seu primeiro ano menos da metade do número de vulnerabilidades divulgadas que o Windows XP no seu primeiro ano, mesmo tendo quase 50% a mais de linhas de código.

Isso para nós da Microsoft é a parte mais importante do relatório. Mostra  o investimento em um processo de desenvolvimento seguro está dando resultados. Mostra que a Microsoft está melhorando. Ainda há muito o que se fazer, claro.

Outra parte do relatório compara estes números de vulnerabilidades encontradas com os de outros sistemas operacionais de desktop, como o Ubuntu Linux, Red Hat Enterprise Linux e Mac OS X. E a coisa não ficou nada boa para este último, e é francamente vergonhoso para distribuições Linux, que tiveram aproximadamente 5 vezes (Ubuntu) ou 10 vezes (Red Hat) mais vulnerabilidades.

Assim como Michael Howard, eu também recebi todo o tipo de desculpa sobre estes números:

■ "Eu uso Linux sem antivirus e nunca tive problema"

■ "A Microsoft esconde as suas vulnerabilidades"

■ "Com estatísticas você consegue provar qualquer coisa"

■ "Nós somos mais seguros porque corrigimos mais vulnerabilidades"

Oops, este último foi a Red Hat!

OK, vamos então deixar a comparação com o Windows de lado por um segundo. Vamos inclusive remover as barras do Windows do gráfico original, e ficar aqui com essa versão:

Não importa como você queira ver, quatrocentas vulnerabilidades encontradas em um ano é muita coisa. Significa mais de uma vulnerabilidade por dia, praticamente duas vulnerabilidades por dia se você contar somente os dias úteis! E note que isso se refere apenas a parte básica do sistema operacional - estamos excluindo aqui os pacotes de escritório, compiladores e tudo mais.

Ainda assim, eu não vejo ninguém admitir isso como sendo um problema. Você esperaria alguém dizer "olha, temos um problema, vamos procurar uma solução para isso". Mas isso nunca veio. Ao contrário, as poucas iniciativas para implementar uma melhoria sistemática na qualidade do software falharam (nesse caso em particular, o responsável acabou depois vindo trabalhar na Microsoft).

O primeiro passo para resolver o problema é admitir que ele existe. A Microsoft reconheceu isso abertamente e embarcou em uma jornada para produzir softwares mais seguros. Outros fabricantes preferem negar que o problema existe. Os números só refletem isso.

SAFECode

O SAFECode (Software Assurance Forum for Excellence in Code) é um fórum onde empresas que desenvolvem software podem trocar experiências e melhores práticas sobre desenvolvimento de código seguro. Participam do SAFECode empresas como Symantec, SAP, EMC, Juniper e claro a Microsoft.

O SAFECode divulgou semana passada o primeiro paper com as práticas de desenvolvimento seguro utilizadas por estas empresas, e é interessante ver como as abordagens utilizadas são relativamente similares. Este é um primeiro passo para depois termos um conjunto de práticas universalmente recomendadas para desenvolvimento seguro, e métricas comuns para avaliar estes processos.