1 comentários

 
GN⁺ 2024-07-22
Comentários no Hacker News
  • Primeiro comentário

    • O problema de BSOD foi causado por uma combinação de dados binários incorretos e um parser mal implementado
    • Com base na experiência dos últimos 10 anos, a maioria dos CVEs, travamentos, bugs e problemas de lentidão ocorre no processo de desserializar dados binários em estruturas de dados legíveis pela máquina
    • Isso se aplica a várias áreas, como algoritmos de compressão, leitores de contornos de fontes, parsers de imagem/vídeo/áudio, parsers de dados de videogames, parsers de XML/HTML e parsers de certificados/assinaturas/chaves do OpenSSL
    • O parser de conteúdo do programa EDR da CrowdStrike também não é exceção
  • Segundo comentário

    • Soluções open source podem ser mais éticas do que softwares de monitoramento de endpoint baseados em rootkit
    • Ferramentas open source operam de forma transparente e podem garantir a ausência de backdoors ou bugs graves
    • Elas podem ser auditadas publicamente, e o negócio pode funcionar com equipes de segurança fornecendo assinaturas de malware
  • Terceiro comentário

    • A Microsoft tem responsabilidade pela interrupção causada pela CrowdStrike
    • A Microsoft ocupa uma posição praticamente monopolista no espaço de computação de workstations e tem o dever de garantir a segurança, confiabilidade e funcionalidade do produto
    • Sem concorrência, a inovação no Windows está atrasada
    • Por exemplo, a CrowdStrike roda em espaço de usuário no macOS e no Linux, mas não no Windows
    • É necessária inovação em sandboxing de aplicações
    • A Microsoft detém as chaves da infraestrutura computacional do mundo e quase não é fiscalizada
    • Embora a participação da receita do Windows tenha diminuído, trata-se de um produto que opera infraestrutura crítica, então é necessária mais responsabilidade
    • O governo deve estimular a concorrência no mercado de workspaces desktop ou regular o produto Windows da Microsoft
  • Quarto comentário

    • Não dá para entender por que o impacto foi tão grande
    • Em serviços críticos, o normal é fazer implantações lentas com monitoramento automático e rollback
    • Também é comum implantar primeiro em beta, sem tráfego de clientes, e expandir gradualmente se não houver problemas
    • Esse método poderia ter interrompido o problema imediatamente
  • Quinto comentário

    • Não uso CrowdStrike, mas parece que o driver CS é instalado primeiro e foi projetado para não poder ser removido
    • O driver carrega arquivos de dados não assinados, e o usuário pode apagá-los arbitrariamente
    • Um usuário mal-intencionado poderia criar um arquivo de dados malicioso e fazer o driver se comportar de forma incorreta
    • Existe o risco de obter privilégios de kernel
  • Sexto comentário

    • Fico me perguntando por que o problema não foi encontrado na implantação de teste
    • É difícil acreditar que não houve testes antes da implantação
    • Toda empresa deveria ter um ambiente de testes antes de fazer deploy
    • Durante o desenvolvimento, é comum instalar pacotes que falham ou causam problemas, mas não é uma boa ideia implantá-los diretamente em produção
  • Sétimo comentário

    • Fico me perguntando se os clientes da CrowdStrike podem opinar sobre as atualizações
    • Também questiono se todos os clientes dão à CrowdStrike permissão total de execução remota de código
    • Espero que autoridades certificadoras e especialistas em criptografia consigam bloquear essas atualizações no sistema
  • Oitavo comentário

    • Fico me perguntando se o "arquivo de canal" é assinado e verificado pelo driver CS
    • Se não for, isso pode ser uma grande vulnerabilidade no rootkit
    • Entradas executadas com privilégios altos deveriam passar ao menos por verificação de integridade
    • O fato de ser possível simplesmente apagar o arquivo de canal sugere que não existe mecanismo de antidetecção