CrowdStrike já tinha danificado Debian e Rocky Linux meses atrás

• Separadamente da grande falha de BSOD no Windows, já houve casos em que uma atualização da CrowdStrike causou indisponibilidade de servidores também em ambientes Debian e Rocky Linux
• Em abril, um civic tech lab viu todos os seus servidores Debian Linux travarem ao mesmo tempo logo após a atualização e se recusarem a inicializar; a recuperação só foi possível após remover o CrowdStrike
• Embora essa configuração Debian fosse considerada suportada, ela não era compatível com a versão estável mais recente do Debian, e a análise de causa raiz confirmou uma lacuna na matriz de testes
• Usuários de Rocky Linux também relataram que, após o upgrade para RockyLinux 9.4, servidores com CrowdStrike travavam por causa de um bug no kernel, e a equipe de suporte da CrowdStrike reconheceu o problema
• Organizações que dependem da CrowdStrike precisam tratar a aplicação de atualizações com mais cautela e ter um plano de contingência para falhas

---

Casos de interrupção no Linux antes da falha no Windows

• O problema generalizado de Blue Screen of Death em PCs com Windows atrapalhou operações em vários setores, como companhias aéreas, bancos e provedores de saúde
  • A causa foi um channel file problemático entregue pela CrowdStrike em uma atualização
  • A CrowdStrike confirmou que esse travamento não afetou Macs nem PCs com Linux
• No entanto, usuários de Debian e Rocky Linux também sofreram interrupções significativas por causa de atualizações da CrowdStrike, o que levantou preocupações sobre os processos de atualização e teste
  • Isso pode representar um risco potencial para clientes que dependem diariamente dos produtos da CrowdStrike

Problemas confirmados em Debian e Rocky Linux

• Travamento simultâneo de servidores Debian

  • Em abril, um civic tech lab relatou que uma atualização da CrowdStrike fez todos os seus servidores Debian Linux travarem ao mesmo tempo e deixarem de inicializar
  • A atualização não era compatível com a versão estável mais recente do Debian, embora aquela configuração Linux fosse considerada suportada
  • A equipe de TI verificou que as máquinas inicializavam novamente ao remover o CrowdStrike e comunicou o incidente

• Demora na resposta e falha nos testes

  • Um membro da equipe envolvida no incidente demonstrou insatisfação com a demora da CrowdStrike em responder
  • A CrowdStrike reconheceu o problema um dia depois, mas levou semanas para fornecer uma análise de causa raiz
  • A análise mostrou que a configuração Debian Linux não estava incluída na matriz de testes da CrowdStrike
  • O membro da equipe criticou: “O modelo da Crowdstrike parece ser empurrar software para as suas máquinas quando eles querem, independentemente de ser uma emergência ou de ter sido testado”

• Travamentos após upgrade para Rocky Linux 9.4

  • Usuários de Rocky Linux relataram que, após o upgrade para RockyLinux 9.4, servidores com CrowdStrike travavam por causa de um bug no kernel
  • A equipe de suporte da CrowdStrike reconheceu esse problema
  • A repetição de problemas de compatibilidade em sistemas operacionais diferentes revela um padrão de testes insuficientes e falta de cuidado

O que as organizações devem preparar

• Para reduzir problemas semelhantes no futuro, a CrowdStrike deve priorizar testes mais rigorosos em todas as configurações suportadas
• As organizações devem aplicar atualizações da CrowdStrike com cautela e preparar um plano de contingência para mitigar possíveis interrupções
• Fontes relacionadas
  • Ycombinator
  • RockyLinux

[click]

Parece que a IA resumiu o anúncio, e não o texto principal.

[xguru]

O site Neowin tem uma estrutura HTML estranha, então todos os anúncios da barra superior estão sendo reconhecidos como parte do corpo do texto. Já corrigi isso.

[GN⁺]

Comentários do Hacker News

• É surpreendente que o ecossistema OSS/Linux, apesar de muitas vezes ser uma pilha de código colada de graça por grupos independentes e frouxamente coordenados, frequentemente seja mais robusto do que software feito por empresas de bilhões de dólares
  Um dos motivos pode ser que programadores de sistemas OSS lavem roupa suja em público. Em vez de “com olhos suficientes, todos os bugs são triviais”, é mais algo como “código ruim fica vergonhoso só de alguém olhar”
  Estou tentando abrir como open source um projeto comercial, e antes de publicar o código-fonte preciso dar uma boa arrumada: melhorar documentação, limpar TODO/FIXME, validar comentários. Mas dentro de codebases comerciais fechadas já vi coisas muito piores, e imagino que a maior parte do software enterprise esteja em nível parecido

  • Software OSS quase não tem incentivo de lucro, então costuma ser escrito para “funcionar”, não para “vender”
    Também há menos pressão de tempo, então atrasar um release não afeta os resultados do trimestre. Vejo software comercial mais como trabalho de marketing do que como trabalho de engenharia
  • O Linus não concordaria, e há um motivo para o kernel sempre erguer barreiras enormes. Ele rejeitaria com toda razão a maior parte do código de user space
    O fato de qualquer coisa fora do kernel funcionar já é um milagre, e isso fica evidente pela frequência com que quebra a cada atualização de distribuição, ou pela frequência com que é preciso recompilar tudo para voltar a funcionar. Em produção, atualizar é um procedimento extremamente estressante
    Nem comecei a falar de áudio e vídeo, e se colocar Wayland por cima vira um pesadelo à parte. Por isso, em vários aspectos, considero o Windows mais próximo do padrão. Ele é maltratado de todos os lados e ainda assim executa tarefas importantes todos os dias em incontáveis máquinas
    Receber compensação financeira ou não não é o ponto; a profundidade das decisões que aparece nos textos do Raymond Chen e outros é muito rara também no mundo OSS
  • Coisas feitas por dinheiro, mas com MBAs tomando as decisões finais, muitas vezes ficam péssimas em comparação com projetos de hobby ou paixão
    Acho que isso não é só algo do meu trabalho, e espero que continue existindo uma comunidade de pessoas que criam coisas porque querem fazer algo útil e ferramentas que elas próprias possam controlar
  • Prazos também devem ser um fator enorme. Muitos desenvolvedores OSS fazem projetos no tempo livre para si mesmos e para outras pessoas, e em um projeto de paixão é mais fácil ter orgulho do próprio trabalho
    Software comercial muitas vezes parece remendado com fita adesiva para cumprir o prazo do gerente, então vira um “tanto faz” e a pessoa fica satisfeita só por ter terminado
  • Acho que chamar de amadores as pessoas que escrevem o código não descreve bem. A maioria provavelmente é formada por pessoas experientes e altamente técnicas, e “frouxamente coordenado” também se aplica a muitas empresas
    No open source, importa o fato de que as pessoas codificam porque se importam. Se você quer tornar algo bom, funcional e inteligente, a chance de sucesso é maior do que quando faz isso apenas por dinheiro ou para evitar passar vergonha

• Comentário relacionado no grande tópico de ontem sobre a CrowdStrike: “A CrowdStrike fez isso com nossa frota Linux de produção em 19 de abril, e desde então eu queria despejar esse rant” [1]
  Depois seguem vários parágrafos de rant
  [1] https://news.ycombinator.com/item?id=41005936

  • Mesmo na análise de causa raiz publicada semanas depois, o cenário que usávamos não estava na matriz de testes. E isso apesar de aparentemente ser uma configuração suportada, rodando a versão n-1 do Debian stable
    Nem a própria análise pós-incidente deles apresentava uma forma prática de impedir que a mesma coisa acontecesse de novo. Porque a estrutura era: “nós empurramos software para suas máquinas quando quisermos, sem teste, independentemente de ser urgente ou não”
  • Não era só um comentário relacionado; parece que este tópico do HN foi usado como fonte principal na matéria

• Sempre que trabalhei nessa área, ficava a dúvida: “essas coisas são realmente úteis?”
  É uma pergunta difícil de responder, mas fico curioso se existe pesquisa independente de terceiros validando a eficácia de produtos como o CrowdStrike. Ou se todo mundo só está piorando a própria vida por causa de teatro de segurança

  • É parecido com tentar estudar a eficácia de vacinas. Ainda assim, você já deu a resposta. Se conseguirem produzir métricas que a diretoria consiga digerir, isso é considerado valioso
    Continua sendo questionável como faz sentido adicionar algo tão intrusivo. Nos anos 90, empresas de antivírus às vezes também criavam vírus, espalhavam pela rede aquilo que elas mesmas fizeram e depois, como num passe de mágica, impediam a infecção para os assinantes
  • Fico pensando se alguém já viu de fato isso bloquear alguma coisa. Afinal, a empresa que fez a ferramenta obviamente também usava o próprio produto
    Se você perguntar na web mundial “alguém já viu?”, alguém vai aparecer, mas há gente demais que sofreu vulnerabilidades de segurança por causa dessas ferramentas, e a quantidade de pessoas que enfrentou problemas de estabilidade e disponibilidade é praticamente igual ao número de pessoas que usam essas ferramentas

• A qualidade dos produtos, de aeronaves a software, está em queda livre. Hoje em dia todo mundo só pensa em receita adicional, então a falta de QA virou o padrão

  • Nossa economia foi minimaximizada para otimizar lucro, e agora parece que entramos na fase de colher isso
    É pelo mesmo motivo que não conseguimos fabricar munição suficiente para enviar à Ucrânia, trazer a fabricação de chips de volta para o país ou construir navios
  • Também contribui o fato de pessoas não técnicas estarem tomando decisões e até cada vez mais desenvolvendo programas técnicos
    Há 15 anos, a maioria das pessoas da indústria realmente queria estar ali, e as exceções eram poucas. Agora virou como qualquer outra profissão, então a maioria dos desenvolvedores mal se importa com o que entrega, e o resultado final acaba sendo uma porcaria
    Nos últimos anos, quase não encontrei desenvolvedores abaixo do nível sênior que de fato testassem o próprio código lixo
  • O custo econômico de errar é menor do que o lucro que se obtém. Até isso mudar, nada vai mudar
  • Isto não é apenas um problema de qualidade de produto
    É uma estrutura em que influenciadores com cheiro de marketing, sem nem saber o que estão fazendo, vendem lixo para gente que tenta cobrir a paranoia criada por fornecedores com checkboxes de compliance. Essas pessoas não entendem modelagem de ameaças nem como um sistema operacional funciona
    Pela tríade CIA, abriram mão completamente da disponibilidade, também sacrificaram parte da confidencialidade ao enviar todos os movimentos do sistema para alguma empresa de nuvem, e tentam obter uma falsa sensação de estabilidade na integridade, que o fornecedor nem garante. Quase nunca vi evidência de que este produto realmente faça alguma coisa em uma arquitetura de segurança adequadamente em camadas
    Isso é o oposto de uma proposta de segurança. É um castelo de cartas erguido sobre mentira e incompetência, e chega literalmente perto da definição de malware. Envia dados para fora sem controle, pode derrubar sistemas com capacidades remotas de comando e controle, e executa código totalmente arbitrário em ring 0
    Em março de 2023, identifiquei tudo isso como um grave risco de negócio, mas as pessoas mencionadas acima forçaram a adoção. Gravei minha discordância e agora pretendo usar isso para cobrar a conta
    Se as pessoas compram, deixa de importar que seja feito como lixo. E de fato está sendo feito como lixo
  • É triste. Há diferenças entre empresas e, pessoalmente, essa é a parte de que mais gosto em engenharia de software, mas muitas grandes empresas cortam o QA assim que surge a oportunidade

• Também houve relatos de que a CrowdStrike injetava DLLs com bug em aplicações Windows, fazendo com que elas pudessem travar mesmo sem culpa do próprio aplicativo
  https://x.com/molecularmusing/status/1808756095860543916

  • Isso é um assunto totalmente diferente. A DLL injetada é um recurso opcional que vem desativado por padrão, e os administradores recebem um aviso explícito para verificar a compatibilidade com a frota antes da implantação
    Há quatro níveis de hooks aplicáveis, cada um mais instável que o anterior, e há avisos repetidos na interface e na documentação. Por exemplo, o XUMD permite que o sensor monitore informações carregando bibliotecas em processos em execução e aplicando hooks em várias APIs de modo usuário
    Parte da telemetria de endpoint só pode ser coletada com hooks em modo usuário. O XUMD fornece informações sobre quais APIs um processo utiliza, e essas informações são usadas por vários mecanismos de prevenção do sensor com base no comportamento cumulativo observado
    Diferentemente do AUMD, a nuvem pode alterar dinamicamente a visibilidade do XUMD sem atualizar o sensor. As configurações são Disabled, Cautious, Moderate, Aggressive e Extra Aggressive, e, quanto mais se avança, maiores os problemas de desempenho ou compatibilidade com aplicações, por isso não é recomendado para produção
    Como o XUMD é carregado em processos de usuário que originalmente não foram desenvolvidos junto com ele, podem ocorrer conflitos, falhas de inicialização ou degradação de desempenho, especialmente em ambientes com outros produtos de segurança instalados. Para ver quais processos carregaram a DLL do XUMD, basta executar tasklist /m csxumd* na linha de comando

• Tudo isso acontece porque as empresas conseguem evitar por contrato a responsabilidade por danos consequenciais
  Assim como não se deveria permitir excluir por contrato a responsabilidade consequencial por perda de vidas, essas cláusulas também deveriam se tornar inexequíveis ou ao menos limitadas

  • Não era isso que a diretiva europeia de cibersegurança pretendia fazer? Aquela diretiva pela qual todo mundo ficou bravo até surgir uma exceção para FOSS

• As afirmações de que “a atualização não era compatível com a versão stable mais recente do Debian, mas essa configuração Linux era listada como suportada” e que “a análise mostrou que a configuração Debian Linux não estava na matriz de testes” parecem bem próximas de fraude
  É como declarar suporte à configuração X e, na prática, nunca testar a configuração X. É como dizer que um carro tem cinto de segurança, mas em nenhum ponto da fabricação verificar se o cinto foi instalado e funciona
  Se uma montadora fizesse isso, acho que seria processada. Não sei por que a CrowdStrike não seria. Dá para entender não oferecer suporte a uma determinada versão de Linux, mas se anunciam suporte e nem sequer testam, isso é no mínimo negligência deliberada e talvez fraude descarada

• Dizer que “ninguém percebeu” soa como uma forma bonitinha de dizer que a CrowdStrike conseguiu abafar isso na imprensa. No post do HN no dia do bug, havia comentários dizendo que as pessoas já tentavam reportar o problema havia meses
  Até o artigo escreve como se as pessoas tivessem percebido o problema. Então quem exatamente não percebeu? Ou os problemas não eram conhecidos o bastante para deixarem de ser ignorados?

  • Você está dizendo que a CrowdStrike suprimiu a cobertura da imprensa? Fico curioso se acha que eles enviaram cheques para o NY Times, WaPo e as grandes emissoras
    A imprensa não se interessa por alguns servidores morrendo, a menos que isso apareça no mundo real de forma visível, como voos sendo interrompidos
  • Lembro de ter visto algo na época, mas achei que pouquíssimas pessoas instalariam esse tipo de software em Linux. E, na prática, realmente são muito poucas empresas
    O raio de explosão foi pequeno, provavelmente menor até do que o de um driver ruim da Nvidia

• Se tem alguém aqui que usa CrowdStrike, fico curioso sobre o que isso faz exatamente. Vejo chamarem de “antivírus”, mas, pelo que aparece instalado no notebook de trabalho, parece mais um keylogger e monitor de atividade
  Dizem “não tenho nada a esconder”, mas ainda assim incomoda que os superusuários da empresa estejam me vigiando

  • Isso ajuda a conseguir o carimbo de aprovação das equipes de segurança, compliance e jurídico
  • Em vez de chamar soluções de antivírus/EDR de malware ou spyware, existe uma solução melhor: não usar o dispositivo de trabalho para coisas pessoais
    O aparelho é propriedade da empresa e é usado para acessar o ambiente corporativo, então é um ponto de responsabilidade que pode causar danos reais se malware de verdade entrar nele. Se você precisa de privacidade, o certo é usar um dispositivo separado

• Em algumas empresas dizem que o CrowdStrike é implantado em todos os endpoints, mas alguém comentou que rodava apenas dentro de uma máquina virtual com recursos limitados e ninguém dizia nada. Também disseram que, por volta daquela época, viram máquinas virtuais falharem
  Outro ex-colega de uma grande empresa contou que o TI simplesmente desistiu de impor compliance nos endpoints Linux. Alguns administradores de TI parecem usar, na prática, uma política de “não pergunte, não conte”
  A ideia é: monte por conta própria uma stack alternativa e faça do seu jeito, desde que não cause confusão nem minta. Se a motivação da imposição é, em grande parte, compliance de checklist, isso faz bastante sentido
  Fico curioso sobre o quanto esse tipo de conformidade maliciosa está disseminado e o quanto contribuiu para que o incidente de abril não virasse uma notícia maior