Além de grandes problemas para muitas empresas e seus clientes, a falha no software da CrowdStrike trouxe também uma grande quantidade de desinformação. Um site que eu vi dizia que a crise tinha sido causada por um problema nos servidores Windows na CrowdStrike... Neste texto vou relacionar alguns questionamentos meus e algumas respostas que eu encontrei (quando possível citando fontes).
O Que A CrowdStrike Faz?
A CrowdStrike é uma firma americana que fornece soluções de segurança. Seus principais clientes são grandes empresas. Um dos seus produtos é o Falcon, que inclui um módulo chamado Sensor que monitora o comportamento das aplicações, para detectar anomalias.
O Que Ocorreu?
Na sexta feira, 19 de julho, a CrowdStrike enviou uma atualização de configuração (já vamos ver mais sobre isso) para todas as máquinas Windows onde o Falcon está instalado. Esta configuração disparou um "erro de lógica" que resultou em um "travamento", com a exibição de uma tela de erro (a famosa "tela azul da morte" ou BSOD em inglês) em muitas máquinas. O Windows reinicia automaticamente após um certo tempo. E aí o erro ocorre de novo, numa repetição sem fim.
Isto está nos "detalhes técnicos" (não muito profundos) da própria CrowdStrike:
https://www.crowdstrike.com/blog/falcon-update-for-windows-hosts-technical-details/
Antes de olharmos mais detalhes, registro aqui um primeiro questionamento: qual a porcentagem da ocorrência do erro? Não vi nenhuma menção a isto; como comentarei adiante existem indícios que pelo menos algumas máquinas (mais precisamente algumas execução do software) sobreviveram ao problema. Esta porcentagem é relevante no que diz respeito a quanto do problema foi causado pela falta de abrangência dos testes (ou sua completa ausência...)
Como Corrige?
A princípio é simples: entre no modo de segurança (safe boot), navege até o diretório onde ficam os arquivos do CrowdStrike e apague os arquivo de configuração problemáticos. Se o seu disco está criptografado com o Bitlocker, você precisa fornecer a chave. Já existem alguns métodos automatizados para isso.
Agora imagine uma empresa com milhares de funcionários, a maior parte deles não técnicos. Nem sempre vai dar para orientar remotamente.
E tem os servidores "na nuvem", onde não dá para pressionar uma tecla para entrar no modo de segurança. Se tiver sorte, dá para restaurar uma imagem boa antiga. Senão é preciso subir uma máquina limpa, montar o disco virtual com os arquivos problemáticos e apagá-los. Acrescente que com centenas de empresas fazendo isso ao mesmo tempo o processo pode ser mais longo que o usual.
Não vamos esquecer também que o Windows às vezes é usado como um sistema operacional embarcado, e aí cada caso é um caso.
Porque Aparece a Tela Azul?
Na maioria dos sistemas operacionais modernos, o código roda em um dentre pelo menos dois modos: kernel e usuário. No modo usuário existem várias restrições quanto ao que pode ser acessado e ser feito, buscando garantir uma separação entre programas. O código que roda no modo kernel tem um acesso bem mais irrestrito e é, normalmente, restrito a componentes críticos do sistema operacional.
Graças à separação e as limitações do modo usuário, quando um erro acontece nele o sistema operacional consegue terminar a execução deste código e seguir em frente. Já quando um erro grave acontece no modo kernel, a maioria das vezes o sistema operacional não tem como isolar o código com erro nem ignorar os seus resultados e é preferível parar a máquina que seguir com o sistema instável.
Um pequeno desvio aqui: o uso do kernel mode em sistemas operacionais foi um dos pontos de polêmica entre Linus Torvalds e Andrew S. Tanenbaum quando do anúncio do Linux. Linus seguiu a tradição do Unix de ter um grande sistema "monolítico" onde grande parte roda no kernel mode (assim como o Windows e muitos outros). Tanenbaum defendeu um sistema mais componentizado, onde apenas uma parte (o micro-kernel) roda em kernel mode e a maioria dos serviços do sistema operacional são fornecidos por código rodando no modo usuário. #TanenbaumWasRight
Por Isso Eu Rodo Linux...
Hold my beer... A CrowdStrike já derrubou sistemas Linux no passado:
https://access.redhat.com/solutions/7068083
Mas o CrowdStrike Sensor Precisava Rodar no Kernel?
O CrowdStrike Sensor, assim como muitas ferramentas de segurança, quer examinar o comportamento bem próximo do sistema operacional. Por exemplo, o objetivo da configuração que deu problema era registrar como os programas estavam usando certas funções do sistema (mais exatamente, o acesso a named pipes). Existe também um jogo de "gato e rato" com os desenvolvedores de malware, que querem evitar ou "pular" estes monitoramentos. Considerando a arquitetura e os recursos do Windows (e outros sistemas operacionais), é prática usual que estes monitoramentos sejam feitos no kernel mode.
Deve-se, é claro, questionar se o trecho em particular que deu erro não poderia ter sido executado em modo usuário.
Cabe notar ainda que a Microsoft tenta restringir o código de terceiros que roda em kernel mode e tem um programa de certificação para estes softwares.
Afinal, o Que São Estes Arquivo de Configuração e o Que Deu Errado?
Não achei uma resposta definitiva a respeito. Parece certo que este arquivo, de alguma forma, determina quais funções do sistema operacional devem ser monitoradas, que comportamentos são relevantes e quais ações devem ser tomadas ao detectar estes comportamentos. Embora estes arquivos tem extensão .sys, não são diretamente código executável (embora já vi algumas especulações de seriam instruções interpretadas pelo código principal do Falcon).
Também está em aberto o que deu errado. Pode ser que o arquivo tenha sido danificado antes de ser enviado. Pode ser que o arquivo tenha sido gerado incorretamente. Pode ser que o arquivo esteja correto mas o código do Falcon tenha se atrapalhado ao analisá-lo. Ou ainda que o arquivo de configuração e sua análise estejam corretos mas o programa falhou ao executar o que ele mandava.
Qual é a "Falha Lógica" Causou a Tela Azul?
Aqui entramos em mais um ponto nebuloso. O motivo imediato da Tela Azul é o acesso a uma posição ilegal de memória. Muitos falam em "null pointer" (usar um ponteiro contendo zero para acessar a memória), mas aparentemente não é isso.
Aqui um outro desvio: os sistemas operacionais modernos usam os recursos de proteção de memória dos processadores para detectar acessos a posições indevidas à memória. Não apenas o endereço zero, mas várias faixas, incluindo endereços baixos. Isto porque muitas vezes o programa com um ponteiro "zerado" pode querer acessar não o primeiro byte mas sim o décimo byte a partir dele (por exemplo).
Correu pela internet um exemplo em que o erro é um acesso ao endereço 0x9c, que originalmente foi considerado como um acesso ao deslocamento 0x9c a partir de um ponteiro nulo. Mas um pesquisador de segurança foi mais a fundo e examinou o código em torno do ocorrido. O que ele observou é que o código está examinando um a um endereços em uma tabela. Após testar que o endereço não é zero, ele acessa a posição correspondente. Só que a tabela tem vário valores ilegais e diferentes de zero.
(fonte: https://x.com/taviso/status/1814762302337654829)
Observou-se também que em outros caso o endereço que causa a parada é outro. Isto leva à especulação de que a tabela não está sendo inicializada corretamente e o seu conteúdo é aleatório. Isto explicaria relatos de máquinas que não apresentaram falhas ou voltaram a funcionar após várias reiniciações. Este fator aleatório na falha dá credibilidade à possibilidade do erro não ter sido detectado antes da atualização ser liberada.
O Que a CrowdStrike Poderia Ter Feito Que Evitaria a Crise?
Não temos informações sobre o processo de liberação destas atualizações de configuração, mas algumas sugestões são óbvias:
- Testar as configurações em mais ambientes
- Liberar as atualizações de forma progressiva
- Deixar o processamento das configurações mais robustos
Vi um comentário (https://x.com/UK_Daniel_Card/status/1814894876258980342) de que os dois primeiros pontos não seriam viáveis dado a quantidade de atualizações de configuração dos softwares de segurança e a necessidade agilidade. Eu acho que é uma questão de achar o ponto correto de compromisso entre agilidade e confiabilidade. A questão da quantidade é resolvida agrupando atualizações e fazendo um processamento automático para montar uma espécie de "linha de produção".
O Que a Microsoft Poderia Ter Feito Que Evitaria a Crise?
Deixando de lado uma mudança estrutural imensa no Windows, acho difícil a Microsoft conseguir evitar a ocorrência de BSOD por falha em componentes de terceiros (ou dela própria) no modo kernel (ou impedir a criação destes componentes).
Onde ela talvez possa melhorar é na recuperação do sistema nestes casos, particularmente nas situações em que não temos um teclado e monitor ligados.
Nenhum comentário:
Postar um comentário