Bugs que Mudaram a Historia: 10 Falhas

1. Therac-25 (1985-1987): Race Condition que Matou Pacientes

A maquina de radioterapia Therac-25 matou pelo menos 3 pacientes e causou lesoes graves em outros 3 entre 1985 e 1987. A causa foi uma race condition: dois processos concorrentes acessavam a mesma variavel de configuracao sem sincronizacao. Se o operador digitava rapido o suficiente para mudar o modo de tratamento antes do sistema processar a entrada anterior, a maquina entrava em um estado inconsistente onde o feixe de alta energia ficava ativo sem o colimador de hardware no lugar.

O que tornou o Therac-25 mais perigoso do que seu predecessor, o Therac-20, foi que o modelo anterior tinha travas fisicas de hardware que impediam configuracoes perigosas. O Therac-25 substituiu essas travas por software, considerado mais confiavel. A retirada das salvaguardas de hardware removeu a ultima linha de defesa. A licao que ficou para a industria: software nao substitui hardware em sistemas onde a falha tem custo de vida.

2. Ariane 5 (1996): Integer Overflow de 370 Milhoes de Dolares

Em 4 de junho de 1996, o foguete Ariane 5 explodiu 37 segundos apos o lancamento. A causa foi um integer overflow: uma variavel de velocidade horizontal armazenada como float de 64 bits foi convertida para um inteiro de 16 bits sem verificacao de limite. O codigo tinha sido copiado do Ariane 4, onde a variavel nunca ultrapassava o limite do int16. O Ariane 5 era mais rapido e a variavel excedeu esse limite durante o lancamento.

Quando o overflow aconteceu, o sistema de navegacao transmitiu dados de diagnostico de erro como se fossem dados de posicao validos. O computador de voo interpretou esses valores como uma trajetoria incorreta e ordenou uma correcao abrupta. A estrutura do foguete nao aguentou o estresse e o sistema de autodestruicao foi ativado. O custo total da missao foi de aproximadamente 370 milhoes de dolares. A analise completa esta em A Historia Nao Contada do Desastre do Ariane 5.

3. Mars Climate Orbiter (1999): Metros vs. Pes

A sonda Mars Climate Orbiter da NASA se perdeu em setembro de 1999 apos uma viagem de 9 meses. O motivo foi um erro de unidade: um subcontratado fornecia dados de navegacao em unidades imperiais (libra-forca por segundo), enquanto o software da NASA esperava unidades SI (newton-segundo). A diferenca acumulada ao longo de meses de viagem colocou a sonda numa trajetoria incorreta. Ela entrou na atmosfera de Marte em um angulo muito raso e provavelmente desintegrou.

O custo foi de 327 milhoes de dolares. O bug ficou escondido porque os valores numericos pareciam razoaveis individualmente, a diferenca so era visivel quando se comparava as trajetorias previstas com as observadas. A NASA implementou revisoes obrigatorias de unidades de medida em todos os projetos interplanetarios como resultado direto desse incidente.

4. Knight Capital (2012): 440 Milhoes em 45 Minutos

Em 1 de agosto de 2012, a firma de trading Knight Capital ativou um novo sistema de negociacao automatizada. Em 45 minutos, o sistema fez 4 milhoes de trades e acumulou uma posicao de 7 bilhoes de dolares em acoes. O prejuizo foi de 440 milhoes de dolares. A causa foi um deploy parcial: codigo antigo que estava desativado foi reativado em 7 dos 8 servidores de producao por um erro de configuracao. O servidor sem a nova versao rodou o codigo legado em loop.

Nao havia runbook de rollback. Levou 45 minutos para desligar o sistema manualmente. A Knight Capital faliu dias depois, sendo adquirida por um consorcio de emergencia. A licao que a industria de fintech absorveu: deploys atomicos onde todos os servidores recebem a mesma versao ao mesmo tempo nao sao opcional em sistemas de alta frequencia.

5. Heartbleed (2012-2014): Dois Anos de Memoria Exposta

O Heartbleed foi uma vulnerabilidade na extensao Heartbeat da OpenSSL descoberta em abril de 2014, mas presente desde 2012. A falha era um buffer overread: quando o servidor recebia uma requisicao de heartbeat, ele copiava de volta a mensagem para o cliente sem verificar se o tamanho declarado na requisicao correspondia ao tamanho real dos dados. Um atacante podia declarar uma mensagem de 64KB enviando 1 byte e receber de volta os proximos 64KB da memoria do servidor, que podia conter chaves privadas, senhas e sessoes ativas.

Dois anos de exposicao, sem rastros nos logs de acesso. Estimativas apontam que 17% de todos os servidores web seguros do mundo estavam vulneraveis. A correcao foi uma unica linha de verificacao de tamanho que deveria ter estado la desde o inicio. O caso acelerou o movimento de financiamento sustentavel para projetos open source de infraestrutura critica, incluindo a criacao da Core Infrastructure Initiative.

6 a 10: Toyota, Boeing, CrowdStrike, Log4Shell e o Padrao Comum

O bug do acelerador da Toyota (investigado entre 2009 e 2011) foi causado por software de controle do motor com logica de gestao de tarefas deficiente que podia entrar em estados inesperados sob condicoes de memoria especificas. Resultou em recalls de mais de 9 milhoes de veiculos e forcou a industria automotiva a adotar verificacoes formais de software embarcado de seguranca. O sistema MCAS do Boeing 737 MAX foi o caso mais recente de software critico de aviaçao sem redundancia suficiente: um unico sensor com falha acionava o sistema que empurrava o nariz do aviao para baixo, sem que os pilotos tivessem treinamento adequado para contrapos-lo. Dois acidentes, 346 mortos.

O incidente da CrowdStrike em julho de 2024 causou a maior interrupção de TI da historia: 8,5 milhoes de computadores com Windows travaram com tela azul apos uma atualizacao de definicao de sensor com um arquivo de configuracao corrompido que passava de ponteiro nulo para o driver do kernel. O Log4Shell em dezembro de 2021 foi uma vulnerabilidade de JNDI injection na biblioteca Log4j do Java que afetou centenas de milhares de aplicacoes. Qualquer string de log que contivesse uma expressao JNDI especial era executada remotamente pelo servidor de log.

O Que Todos Esses Bugs Tem em Comum?

Olhando os dez juntos, aparece um padrao claro. Nenhum foi causado por incompetencia tecnica obvia. Todos foram causados por suposicoes razoaveis que se tornaram invalidas, pela ausencia de camadas de defesa independentes, ou por confiança excessiva em codigo herdado ou em atualizacoes nao testadas em escala real. Em sistemas criticos, a falha de um componente nao deveria causar a falha do sistema inteiro. Esse principio, chamado de fault tolerance ou defense in depth, e o que separa engenharia de software critico de desenvolvimento convencional.

Esses bugs poderiam ter sido evitados com code review?

Alguns sim, outros nao. O Heartbleed provavelmente teria sido pego por um revisor atento verificando bounds checking. O Knight Capital teria se beneficiado de um review de processo de deploy. Mas o Therac-25 e o Ariane 5 eram casos onde o bug so se manifestava em condicoes especificas de timing ou de escala que code review convencional nao teria detectado. Esses casos exigem analise formal de sistemas, fuzzing e testes em condicoes que reproduzem o ambiente real de operacao. O guia de code review para prevenir bugs criticos cobre as tecnicas praticas para cada categoria.

Por que bugs criticos ainda aparecem com todo o conhecimento acumulado?

Porque o conhecimento de engenharia de software e fragmentado entre industrias, nao e obrigatorio em curriculos de ciencia da computacao e nao e transmitido sistematicamente entre geracoes de devs. Um dev que nunca ouviu falar do Ariane 5 pode escrever uma conversao de tipo sem verificacao de bounds e nao saber que isso ja destruiu um foguete. O conhecimento de casos historicos nao e trivia: e o mapa dos tipos de erro que aparecem em sistemas reais. Cada bug novo que causa um desastre e quase sempre uma variacao de uma categoria que ja existia antes.