Eu ainda não era gente quando falava-se do “Bug do Milênio”, mas a história dele ainda me foi ensinada quando eu brevemente cursei Ciência da Computação.

Para quem não sabe: Nos anos 70, quando computadores estavam começando a se espalhar pelo mundo, eles tinham sérias limitações de memória de trabalho e de armazenamento. Como tal, engenheiros e programadores usavam todo tipo de “atalho” para resolver problemas e economizar recursos.

Um destes atalhos tinha a ver com como computadores armazenavam datas: Especificamente, o fato de que eles reservavam apenas dois dígitos para o ano. Isso fazia sentido em 1970, Economizava memória, que na época tinha de ser racionada cuidadosamente – E com 30 anos sobrando no século XX, todo mundo envolvido foi empurrando o problema adiante.

Certamente, eles pensavam, quando chegasse a virada do milênio, ninguém estaria usando esses sistemas montados às pressas, com seus atalhos econômicos. De fato, algo que eu citei em uma coluna passada, sistemas Unix foram desenvolvidos desde 1969 preparados para contar datas muito além do século XXI

Bem, surpresa, chegou 1995, computadores agora estavam em todas as empresas no primeiro mundo, e lentamente invadindo casas de famílias e empresas no terceiro mundo – E ainda assim, sistemas desenvolvidos nos anos 70, e incapazes de contar datas além de Dezembro de 1999, estavam por toda parte. E a indústria tecnológica global coletivamente entrou em pânico.

No fim das contas, o tal bug do milênio foi um grande nada: a anedota que se conta é que uma video locadora em Nova Iorque tentou cobrar uma multa milionária de um cliente, e nada mais aconteceu.

O bug foi evitado… Devido ao trabalho de milhares de programadores e engenheiros, que ao reconhecer o problema, iniciaram a tarefa hercúlea de preparar os computadores já existentes para resistirem ao problema, e de garantir que computadores futuros seriam feitos já blindados.

Bem, 24 anos depois, milhares de empresas e indivíduos por todo o mundo se viram afetadas por um apagão digital que em muitos sentidos parece o cenário apocalíptico que o bug do milênio prometia ser e não foi: Pessoas presas em aeroportos porque os sistemas das linhas aéreas e torres de controle estavam offline, sistemas de bancos inacessíveis, e tudo o mais.

Este post vai ser particularmente técnico e cheio de jargão. Sinto muito, mas não tem outro jeito de explicar o que aconteceu aqui.

Quando o perigo vem de dentro

Como explicado na reportagem feita aqui no Post mesmo sobre o assunto, o apagão não foi resultado de um ciberataque ou incidente de segurança. Pelo contrário, foi uma falha em um componente interno dos sistemas, devido a um erro cometido por um dos serviços que seriam responsáveis por impedir quedas desse tipo. – Um software chamado CrowdStrike Falcon.

Primeiro: O que é o Falcon? Como dito, CrowdStrike é uma empresa de cibersegurança, e o Falcon é um software deles que busca tornar o sistema operacional mais robusto contra todo tipo de ataque, agindo como uma espécie de sensor, capaz de reconhecer e responder em tempo real não apenas a malwares tradicionais (Vírus, Trojans, etc.), mas coisas mais avançadas e esotéricas, como zero-day exploits e violação de ferramentas integradas do ecossistema. Encontrado principalmente em servidores, onde tais riscos de segurança podem representar prejuízos milionários.

Por necessidade, um software como o Falcon precisa ter acesso privilegiado ao computador, capaz de ver o que outros programas estão fazendo e interferir diretamente com eles.

Em termos tecnológicos, isso é chamado “Modo Kernel” – Programas executando em “Modo Kernel” têm acesso a toda a memória do computador o tempo todo. E há meia dúzia de boas razões pelas quais a maior parte dos programas não têm este nível de acesso.

De fato, a maior parte dos aplicativos que usamos no dia-a-dia operam no chamado “Modo Usuário”, ficando “presos” em uma cápsula definida pelo SO, com acesso a coisas fora da cápsula sendo mediado pelo sistema. Isso tem algumas desvantagens, é mais lento e adiciona complexidade.

Quem usou computadores entre 95 e 2001 vai lembrar da mensagem de erro “este programa executou uma operação ilegal” – Em 99% dos casos este erro acontecia porque um programa em modo usuário havia, por malícia ou incompetência, tentado mexer com partes da memória que estavam fora de sua cápsula. Programadores da época ainda estavam se adaptando a este mundo de programas encapsulados e níveis de privilégio, afinal, o velho DOS não tinha nada disso. Rodava um programa por vez, e este programa podia mexer no computador inteiro.

Mas a vantagem é que quando um aplicativo em modo usuário trava ou faz algo que não devia, o sistema é capaz de capturar isso, fechar o programa problemático, e continuar funcionando.

Por outro lado, qualquer erro em um programa no modo kernel vai, necessariamente, derrubar o sistema inteiro.

E isso é intencional. Devido ao acesso privilegiado que um programa de modo kernel possui, se ele pára de funcionar, ou outro componente do sistema detecta que ele está fazendo algo que não devia, simplesmente fechá-lo e seguir em frente como se nada tivesse acontecido poderia ter resultados desastrosos, corrompendo arquivos por todo o computador de forma irreversível. Então por razões de segurança, quando algo dá errado em um programa desses, o sistema inteiro é desativado, e o usuário é instruído a reiniciar o computador inteiro.

Sabendo disso, é fácil de entender por que a maior parte dos programas não encosta no modo kernel. Mas o software da CrowdStrike tinha esta permissão: A CrowdStrike é uma empresa parceira da Microsoft, e o software Falcon possui o certificado WHQL – Que normalmente é reservado para drivers de hardware, e significa que o programa foi rigorosamente testado pela Microsoft em máquinas e situações diversas, e é oficialmente marcado como “este programa, apesar de ter acesso ao modo kernel, não vai te dar dor de cabeça” pela empresa.

Mas aqui uma tensão fundamental se manifesta: Considere um driver para algo como uma placa de vídeo ou um adaptador de rede ou o que for. Uma vez comprada, essa peça vai ficar no computador um bom tempo, e um driver funcional é tudo o que ela precisa. Claro que os drivers são periodicamente atualizados para ficarem mais rápidos e eficazes, mas a lentidão de passar pelo processo de certificação toda vez não é um problema.

No entanto para um programa como o Falcon, que precisa responder com imediatez a ameaças digitais, este processo de certificação é, sim, um problema. Então o que a CrowdStrike fez foi, como nos anos 70 com o bug do milênio, inventar um “atalho”.

O que o Falcon faz é que o programa em si é atualizado devagarinho e portanto passa pelos testes rigorosos da WHQL, mas ele lê várias informações cruciais de um “arquivo de definições dinâmicas” separado, e este arquivo é atualizado sem passar por qualquer processo de validação externa. Isso tem a vantagem de dar a eles agilidade.

Mas a desvantagem é que este arquivo de “definições” é na verdade um programa por si próprio, executado indiretamente pelo Falcon, sim, mas ainda assim um programa não-certificado executando em modo kernel. Tudo o que é preciso para derrubar o sistema todo – É um pequeno erro, algo tão simples quanto um NullPointer no código.

Embora não se saiba exatamente o que deu errado – Foi exatamente algo do tipo que aconteceu. A CrowdStrike atualizou seu arquivo de definições, e um erro nele foi capaz de derrubar milhares de servidores baseados em Windows pelo mundo inteiro.

Haviam formas que a CrowdStrike podia ter impedido isso – Se o Falcon tivesse mais passos de validação para garantir que o arquivo de definições não teria erros antes de incorporá-lo. Ou fosse capaz de se recuperar de erros sem travar. Mas bem, não foi isso que aconteceu. Com as definições bugadas, o programa inteiro travou, e como ele é um programa em modo kernel, a única coisa que o sistema poderia fazer a partir daí, era parar tudo.

Como eu disse em minha última coluna, um sistema operacional moderno é uma lasanha com dezenas de camadas, e portanto, às vezes eles parecem aleatórios e caóticos. O que aconteceu aqui foi que uma destas camadas ruiu. Eu não tenho realmente uma conclusão a tirar aqui: Nossas vidas estão pesadamente investidas na tecnologia, e essa tecnologia tem “buracos” que não existiam na época do protocolo impresso. Mas é igualmente impossível enfiar o gênio de volta na garrafa.

Escrito por Vitor Germano para o Maringá Post
Me mande suas perguntas tecnológicas no e-mail [email protected]