Você confia nos programas que você utiliza? Você toparia uma cirurgia remotamente, com seu médico a km de distância utilizando os recursos da telemedicina? Você confia que os automóveis mais modernos disponíveis te levarão de um ponto a outro do globo terrestre sem que você encoste no volante? Você confia que as empresas nas quais você armazena seus dados estão fazendo tudo para manuseá-los/preservá-los com segurança e que o acesso às suas informações é restrito? Você confia que os softwares que você utiliza são testados exaustivamente a procura de brechas que possam resultar num incidente de segurança? Se você respondeu que sim a todas as perguntas anteriores, parabéns! Eu queria ser você, mas simplesmente não consigo.
A confiança nos dispositivos computacionais e eletrônicos, na minha opinião, nunca estiveram tão em baixa, seja em software ou hardware (o que por um lado, ajuda a manter aquecido o mercado de segurança da informação). Já é um mantra do pessoal de segurança em TI que "100% de Segurança não existe", mas devemos nos acostumar também ao fato de que "Código de programa bem escrito, 100% bug free", também é lenda urbana. Todo programa tem suas vulnerabilidades e o fato de você não as encontrar, ou mesmo os especialistas de segurança não as encontrarem, não significa que seu programa esteja livre de erros, significa apenas que os erros não foram encontrados! Ele pode permanecer anos invisível no seu ambiente até que alguém o descubra e, sendo pessimista, o explore (e sob esse ponto de vista é bem melhor saber sobre a falha e corrigi-la do que simplesmente não saber da sua existência).
Claro que alguns erros tem proporções ínfimas, e não são motivo de tanta preocupação. Uma aplicação que executa uma função inválida e trava o seu computador, trará muito menos dor de cabeça do que um foguete espacial que se desintegrou ao receber uma informação errônea (e veremos esse caso adiante). E com esse pensamento, procurei na Internet alguns casos que mostram que um código vulnerável (ou um programa mau escrito, como queira), é um dos principais problemas que temos na segurança da informação. Aponte um programa que não tem falhas. Pense sobre os programas e sistemas operacionais que você utiliza; agora vá no Google e digite "Falha de segurança no [coloque aqui o programa que você pensou]". Conseguiu encontrar algum que não retornasse nenhum resultado? Note que nem todos esses casos citados abaixo estão relacionados à segurança da informação, mas servem para exemplificar o quão difícil é projetar e implementar códigos livres de bugs. Veremos casos de agências espaciais internacionais como a NASA que possuem recursos de sobra e um forte incentivo para certificar-se da qualidade de seus programas e mesmo assim falharam e apresentaram bugs que custaram alguns milhões (em casos de outras empresas, algumas vidas).
E por falar em "bug", pesquisando na Internet, você encontrará diversas "lendas" dizendo que o termo "bug" surgiu em 1945 quando Grace Murray Hopper (uma das pioneiras na programação do famoso Harvard Mark I e II e responsável por popularizar a ideia de linguagens de programação independentes do hardware, levando ao desenvolvimento do COBOL - COmmon Business Oriented Language), documentou o primeiro bug da informática. Segundo essa lenda, no dia 9 de setembro de 1945 seu grupo de trabalho encontrava-se na sala do Mark II tentando identificar porquê o computador não funcionava adequadamente. Após uma inspeção minuciosa, encontraram no "Painel F" uma mariposa entre os contatos de um dos relés do computador. No caderno de registros, Grace registrou o incidente como "First actual case of bug being found" (encontrado o primeiro caso de bug) e "anexou" junto da inscrição a famigerada mariposa ;o) associando pela primeira vez o termo "bug" a um erro num sistema computacional. A partir de então, quando os computadores apresentam falhas, é normal usar o termo bug para referenciar tais falhas (vindo daí também o termo "debug").
.jpg)
Na verdade, conforme o site ComputerWorld, o termo bug surgiu bem antes mas ainda assim é uma lenda que vale a pena ser mantida, em função dos serviços prestados pela sra. Cooper. Segundo o site, dois argumentos invalidam a origem do termo conforme o relato de 1945:
1 - O Harvard Mark II entrou em operação no verão de 1947, dois anos após a data atribuída para essa história e;
2 - não se usa um termo como "Encontrado o primeiro caso de bug" se a expressão "bug" não for de uso comum, ou seja, rotineira no ambiente em que foi utilizada. Esse tipo de comentário não faria sentido a não ser como uma mensagem bem humorada para um erro.
Engenheiros e cientistas já falavam sobre bugs, um século antes do incidente da "mariposa no relé", incluindo Thomas Edison, inventor de diversos dispositivos (entre eles a lâmpada elétrica incandescente), que em 1878, numa carta enviada a Theodore Puskas escreveu: "Bugs - como essas pequenas falhas e dificuldades são chamadas - aparecem e meses de observações, estudos e trabalhos intensos são necessários antes do sucesso ou fracasso comercial ser atingido com precisão". Estudiosos inclusive "rastrearam" a palavra bug a um termo que fazia referência a um monstro, uma palavra que sobreviveu em termos obscuros como "bugaboo" (bicho-papão) e "bugbear" (pesadelo) e de forma mascarada na palavra "boogeyman" (bicho-papão).
Independente de onde/quando o termo tenha sido utilizado pela primeira vez, vejamos alguns casos onde um "simples errinho de programação", causou danos significativos. Veja que nem todos os casos são de programas mau escritos, alguns envolvem falta de testes, erros diversos ou uso incorreto, mas sou da opinião que fundamentalmente, os softwares deveriam estar preparados para o uso incorreto.
(clique nos links abaixo das imagens para ser direcionado até a página de origem da foto)
1962 - Sonda Mariner
Em 28 de julho de 1962 um bug no software da sonda Mariner I (cujo destino era Vênus), desviou seu percurso de voo logo após o lançamento, fazendo com que o controle da missão destruísse o foguete cerca de 5 minutos após a decolagem enquanto ele sobrevoava o oceano Atlântico. A investigação do acidente determinou que o problema estava numa fórmula escrita a lápis que foi imprecisamente inserida no computador de cálculo (o programador se esqueceu de inserir uma "/", e sem ela o software tratava variações normais de velocidade como se fosse um problema grave, gerando falhas e enviando o foguete para fora de curso). O custo da falha foi de 18,5 milhões de dólares.
1978 - Coliseu Hartford
Uma falha no desenvolvimento do programa utilizado para projetar o Coliseu Hartford em Connecticut, EUA, (que não previa o peso acumulado da neve), causou o desabamento do telhado da arena durante uma
tempestade de neve que teve duração de 10 dias. Apesar de uma partida ter sido disputada no coliseu apenas 6 horas antes do ocorrido, não houve feridos; ainda assim, o prejuízo foi de 70 milhões
de dólares.
Coliseu Hartford
1982 - Explosão no Gasoduto Transiberiano
Considerada a maior explosão não nuclear registrada até hoje, a explosão desse gasoduto teve origem num erro de programação. As informações dão conta que o governo soviético adquiriu um sistema canadense para controlar o gasoduto Transiberiano, com o objetivo estratégico de roubar ou obter de maneira sigilosa informações sensíveis sobre a tecnologia americana. Quando a CIA (agência de inteligência central americana) tomou conhecimento da compra, infiltraram um bug no sistema que a princípio deveria passar pela inspeção soviética porém ocasionar má operação, além de permitir aos americanos manipular remotamente todo o tipo de máquinas e tecnologia. Mas em 1982 quando o bug foi ativado as coisas saíram completamente diferentes do esperado, provocando a gigantesca explosão. Felizmente, como aconteceu numa área remota, não houve vítimas.
1983 - A "quase" 3º Guerra Mundial
Uma falha no sistema de alerta da União Soviética indicou, em 1983, que 5 mísseis balísticos intercontinentais haviam sido lançados pelos Estados Unidos. Detalhe: exatamente um período em que essas nações estavam na chamada Guerra Fria!!!! O então tenente-coronel Stanislav Yevgrafovich Petrov estava como um oficial
de serviço no dia 26 de setembro 1983 no Serpukhov-15, um poderoso bunker
em Moscou, de onde controlava-se o sistema de alerta antecipado de mísseis americanos. Ao invés de informar seus superiores, Stanislav (contra o protocolo militar estabelecido), preferiu esperar os primeiros impactos de solo para só então tomar as contra medidas que fossem necessárias. Felizmente foi uma falha do sistema soviético que, diga-se de passagem, jamais havia falhado. Os sensores dos satélites de alerta tinha experimentado uma situação
estranha, que fez a luz solar refletida por nuvens em elevadas
altitudes, parecerem disparos de misseis, ativando a rede de alarme. História completa aqui.
1985 - Therac-25
O Therac-25 era um acelerador linear utilizado para o tratamento de tumores na década de 80, produzido pela Atomic Energy Canada Limited - AECL. Ele emitia radiação de alta energia sobre células cancerígenas sem causar dano ao tecido circundante. Devido a uma falha de programação (um bug sutil chamado "race condition"), um técnico configurou acidentalmente o Therac-25 para emitir 100 vezes mais a energia do que o necessário (o feixe de elétrons seria como um fogo de alta potência). Como consequência, 6 pessoas morreram em função das altas doses de radiação recebidas e várias dezenas também sofreram os efeitos, inclusive os próprios funcionários. O software não
reconhecia quando doses exageradas eram aplicadas, fazendo com que
alguns pacientes morressem pouco depois da exposição. Este caso tornou-se um ícone para os estudantes de informática na saúde e engenharia de software.
1988 - O worm de Morris
O primeiro worm de Internet, também chamado de Morris Worm, foi criado por Robert Morris Jr. e apenas na tarde do dia 2 de novembro de 1988, infectou entre 2.000 e 6.000 computadores em menos de um dia (o que correspondia a 10% da Internet na época). Morris que é filho do na época cientista chefe
do Centro Nacional de Segurança Computacional dos EUA, foi o primeiro a
ser condenado pela lei de Abuso e Fraude de Computadores, mas pagou
multa de US$ 10 mil e prestou serviços comunitários. O worm de Morris fazia um buffer overflow no daemon finger do Unix que possuía uma falha no código.
1990 - Pane nas linhas da AT&T
No dia 15 de janeiro de 1990 uma única linha de código numa atualização de software implementada para acelerar chamadas causou uma pane com efeito cascata na gigante da telefonia americana AT&T. Este bug no software que controlava os equipamentos de telefonia de longa distância, fez com que a unidade de comutação com erro, informasse as unidades vizinhas que estava com problemas. Infelizmente, a unidade de comutação vizinha também travava ao receber essa mensagem (não sem antes passar a mensagem adiante), gerando um efeito em cascata. Cerca de 9 horas e 75 milhões de ligações perdidas depois, o problema foi resolvido.
1991 - Falha de mísseis Patriot acaba em desastre
No dia 25 de fevereiro de 1991, durante a primeira Guerra do Golfo, o sistema americano dos mísseis Patriot falhou ao interceptar um míssil vindo do Iraque que atingiu uma base americana em Dhahran na Arábia Saudita, matando 28 soldados e ferindo outros 110. Um erro de arredondamento no cálculo e consequentemente na medição do tempo, ocasionou um deslocamento na posição da região de procura do radar da
ordem de 687 metros o que conduziu à não detecção do míssil Scud iraquiano (segundo esse site, o erro grosseiro ocorreu em função de terem se passado 100 horas sem que o sistema fosse reiniciado). Mais informações técnicas explanando o exato problema do erro de arredondamento aqui.
1992 - Acidente do Raptor F-22
Em abril de 1992 um avião Raptor F-22 caiu ao pousar na Base Aérea Edwards na Califórnia. Após investigação, descobriu-se que a causa do acidente foi um erro no software de controle de voo que falhou ao impedir uma oscilação induzida pelo piloto.
Em abril de 1992 um avião Raptor F-22 caiu ao pousar na Base Aérea Edwards na Califórnia. Após investigação, descobriu-se que a causa do acidente foi um erro no software de controle de voo que falhou ao impedir uma oscilação induzida pelo piloto.
1993 - Falha da divisão de números de ponto flutuante nos processadores Pentium
Em 1993 um problema com os então novíssimos microprocessadores Pentium da Intel (que vieram para substituir os 486), trouxeram enorme prejuízo à empresa. O divisor da unidade de ponto flutuante do Pentium tinha uma tabela de divisão insuficiente, faltando cerca de 5.000 entradas, o que resultava num erro de arredondamento. Por exemplo, ao dividir 4195835,0 por 3145727,0 o resultado apresentado pelo microprocessador era 1,33374 ao invés de 1,33382, um erro de 0.006%. Ainda que esse tipo de falha afetasse poucos usuários, a Intel assumiu o erro mas inicialmente se propôs a trocar apenas os processadores de quem conseguisse provar que usava o computador para cálculos matemáticos que exigissem precisão absoluta. A resposta das centenas de milhares de consumidores que haviam pago mais de $600 pelo processador foi dura (ahhh se isso acontecesse com os fabricantes de software) e a Intel viu-se substituindo os processadores de todos os clientes que o solicitaram, arcando com um prejuízo de $450.000.000,00.
Em 1993 um problema com os então novíssimos microprocessadores Pentium da Intel (que vieram para substituir os 486), trouxeram enorme prejuízo à empresa. O divisor da unidade de ponto flutuante do Pentium tinha uma tabela de divisão insuficiente, faltando cerca de 5.000 entradas, o que resultava num erro de arredondamento. Por exemplo, ao dividir 4195835,0 por 3145727,0 o resultado apresentado pelo microprocessador era 1,33374 ao invés de 1,33382, um erro de 0.006%. Ainda que esse tipo de falha afetasse poucos usuários, a Intel assumiu o erro mas inicialmente se propôs a trocar apenas os processadores de quem conseguisse provar que usava o computador para cálculos matemáticos que exigissem precisão absoluta. A resposta das centenas de milhares de consumidores que haviam pago mais de $600 pelo processador foi dura (ahhh se isso acontecesse com os fabricantes de software) e a Intel viu-se substituindo os processadores de todos os clientes que o solicitaram, arcando com um prejuízo de $450.000.000,00.
1994 - Calculadora do Windows 3.x
Um erro na calculadora que acompanhava as versões de Windows 3.x fazia com que a subtração de 2.1 de 2.11 resultasse no valor "0.00" ao invés de "0.01".
No dia 02 de junho de 1994 um helicóptero Chinook da Força Aérea Real Britânica caiu no Mull of Kintyre (região montanhosa situada no ponto mais extremo ao sudoeste da Península Kintyre na Escócia onde se localiza um farol histórico, imortalizada numa canção de Paul McCartney nos anos 70). O acidente que matou 29 pessoas (25 passageiros e 4 tripulantes) teve inicialmente sua causa atribuída a erro humano. Após uma investigação porém, foram descobertas evidências suficientes de que o acidente tenha sido causado por um bug no software do computador de controle do motor da aeronave.
O ping da morte era um ataque de DoS (Denial of Service ou Negação de Serviço) a um computador, que explorava uma má implementação do protocolo TCP/IP nos sistemas operacionais. O ping da morte enviava um pacote mal formado com um tamanho de pacote absurdamente elevado e com uma frequência muito alta. Esse tipo de ataque afetava uma grande variedade de sistemas como Unix, Linux, Mac, Windows, impressoras, roteadores e etc. Em sistemas Windows, o ataque geralmente resultava na famosa "Tela azul da morte". Entre 1997 e 1998 a grande maioria dos sistemas foi corrigido.
1996 - Explosão do Foguete Ariane
Em 4 de junho de 1996 a estação espacial europeia lançou o foguete Ariane-5 contendo 4 satélites para estudar como o campo magnético da Terra interage com os ventos solares. O foguete desintegrou-se 40 segundos após o seu lançamento. O problema aconteceu quando o computador de orientação tentou converter a velocidade do foguete expressa com 64-bits para um formato de 16-bits. O número era muito grande para ser armazenado por uma variável de 16-bits e acabou ocasionando um overflow. Quando o sistema de orientação desligou, o controle foi passado para uma unidade redundante idêntica que também veio a falhar por rodar o mesmo algoritmo. Nesse caso existem 2 situações cruciais para serem analisadas sobre a ótica da segurança:
1 - Os cientistas que desenvolveram o Ariane-5, reutilizaram parte do código do Ariane-4. A função errônea fazia parte de um requisito do Ariane-4 que não fazia parte da especificação do Ariane-5.
2 - Os resultados fornecidos pelo segmento de código que resultaram no erro eram relevantes apenas antes da decolagem. Após a decolagem esta função não servia para nada.
O prejuízo foi de $500.000.000,00.
1997 - USS Yorktown
Um membro da tripulação de um cruzador de mísseis guiados USS Yorktown inseriu por engano um valor "0" num determinado dado que resultou numa "divisão por 0" causando um buffer overflow. O erro teve um efeito em cascata derrubando toda a rede de 16 computadores e eventualmente desligando o sistema de propulsão do navio. O navio permaneceu por quase 3 horas inoperante na água (ou como eles chamam: "dead in the water"), simplesmente porque um programa não validava os dados de entrada. Ainda segundo os engenheiros: "Usar Windows NT ao invés de Unix num ambiente tão crítico foi uma bola fora" e que a decisão de usar Windows NT ao invés de Unix no programa foi uma decisão política equivocada e não uma decisão técnica. Reportagem aqui.
1999 - Destruição das sondas Mars Polar Lander e Mars Climate Orbiter
No dia 3 de dezembro de 1999 a sonda Mars Polar Lander estava se preparando para pousar quando houve um desligamento prematuro do motor antes que ele tocasse o solo. Quando o
aterrizador se encontrava a 40 metros da superfície, suas pernas de
pouso se abriram e o balanço causado no aterrizador pode ter gerado sinais espúrios nos sensores, levando o
computador a considerar que já havia pousado e procedendo o desligamento do
motor de descida (situação que não havia sido prevista pelos desenvolvedores). Os cientistas acreditam que a sonda espatifou-se no solo de Marte a uma velocidade de 22 metros/segundo. O custo da missão excedeu os U$120.000.000,00.
Já a Mars Climate Orbiter foi uma sonda lançada pela NASA no dia 11 de dezembro de 1998 e que chegou a Marte em 23 de setembro de 1999. A nave espacial deveria efetuar sua inserção na órbita de Marte a uma altitude de 140 km a 150 km da superfície, mas devido a um erro de cálculo essa manobra ocorreu a 57 km da superfície causando a destruição da nave (devido a sua fricção com a atmosfera de Marte). O erro aconteceu devido a equipe em Terra ter utilizado o sistema imperial (polegadas e libras) para calcular os parâmetros da manobra de inserção enquanto os sistemas na nave utilizavam apenas o sistema métrico (metros e Newtons).
Mars Polar Lander Mars Climate Orbiter
1999 - Problemas na emissão de passaportes britânicos
No verão de 1999 a agência de passaportes no Reino Unido implementou um novo sistema da Siemens para controlar a emissão de passaportes. Ao mesmo tempo, uma mudança na lei exigia que todos os menores de 16 anos viajando ao exterior deveriam emitir passaporte (o que resultou numa procura enorme para emissão de novos passaportes). Porém o novo sistema não havia sido testado de forma adequada, bem como seus funcionários não haviam recebido o treinamento necessário. Como resultado, meio milhão de cidadãos britânicos não conseguiu emitir seus passaportes e o custo da imperícia foi em torno de £12.6 milhões.
Imagem ilustrativa de passaportes britânicos
1999 - Bug do milênio
O bug do milênio consistia no fato de uma boa parcela dos softwares gerenciar datas com apenas 2 dígitos (fazendo com que "1998" fosse referenciado como "98", ficando subentendido que na frente desses haveriam os dígitos "19"). O problema aconteceria quando, no ano "2000", os softwares considerariam o ano "00" como "1900", causando diversos problemas como boletos de cobrança sendo emitidos com cem anos de atraso, por exemplo. Embora nenhuma falha significativa tenha ocorrido, as empresas correram para atualizar seus sistemas numa espécie de pânico coletivo. É possível que um problema similar aconteça em 2038 (o problema do ano 2038). Os sistemas Unix calculam o tempo em segundos desde 01 de Janeiro de 1970 e armazenam este número como um inteiro de 32 bits signed (que considera o sinal). O valor máximo possível com essa representação é 231, ou seja, 2.147.483.647 segundos, valor que será atingido as 03:14:07 do dia 19 de Janeiro de 2038.
2000 - Vítimas de um Tratamento de Câncer no Panamá
Em novembro de 2000, no Instituto Oncológico Nacional na cidade do Panamá, numa série de acidentes e falhas dos engenheiros da Multidata Systems International calcularam erroneamente a dosagem de radiação que os pacientes deveriam receber durante uma terapia de radiologia. A falha estava no software de controle da máquina de raios software RTP/2 (vers. 2.11, 1991), que provocou
a morte de 8 pacientes e fez com que outros 20 recebessem sobredosagens que poderiam causar graves danos a
sua saúde.
2004 - Falha em atualização gera prejuízo para governo Britânico
Uma falha no sistema para distribuição de bolsas assistenciais originados por dois softwares da Electronic Data Systems (EDS), gerou enormes prejuízos ao governo Inglês. Ao longo de 2004 os dois sistemas da EDS (o Child Tax Credit e o Working Tax Credits) repassaram cerca de 27 bilhões de dólares a 5,7 milhões de
famílias, mas praticamente um terço delas recebeu pagamentos extras no
ano, em virtude das falhas (o prejuízo superou £1 bilhão e resultou na renúncia do chefe da CSA - Child Support Agency, Doug Smith). Um memorando interno da EDS vazou para a mídia onde a empresa admitia que o sistema da CSA foi "mal projetado, mal testado e mal implementado".
2005 - Perda do satélite europeu CryoSat-1
No dia 8 de outubro de 2005, o satélite CryoSat-1 da agência espacial europeia foi perdido durante uma falha no seu lançamento. A falha aconteceu porque não havia um comando para desligamento do segundo estágio do motor do foguete no sistema de controle de voo do seu foguete Rokot. Isto impediu que o segundo estágio se separasse do Briz-KM e o foguete foi impedido de alcançar a órbita.
2005 - Sistema de proteção contra cópia da SONY
Em outubro de 2005 a Sony produziu um esquema de proteção contra cópias denominado SONY DRM rootkit (XCP) que instalava um rootkit nos computadores com Windows XP. A intenção era esconder o mecanismo de proteção para ser mais difícil de burlar, mas infelizmente esse rootkit abria uma brecha de segurança que permitia a instalação de cavalos de Tróia por terceiros nos computadores de quem executasse o CD.
2006 - Vulnerabilidade do OpenSSL
Na tentativa de resolver um problema, um mantenedor do Debian fez uma atualização do OpenSSL e quebrou o gerador de números aleatórios nesse processo. Trecho do alerta do CAIS disponível aqui: "Devido a uma modificação introduzida pelo Debian no pacote OpenSSL
original, existe uma vulnerabilidade na geração de números aleatórios, o
que faz com que essas aplicações gerem sempre um número limitado e
pequeno de chaves criptográficas. Com isso um atacante de posse de uma
lista dessas chaves pode realizar ataques de força bruta contra as
aplicações e conseguir acesso ao conteúdo criptografado."
2007 - Excel informando valor incorreto
A Microsoft lançou uma correção para o Microsoft Excel 2007 que corrige um erro onde era apresentado o número 100.000 como resultado de cálculos que deveriam resultar em 65.535 ou 65.536.
2007 - Atualização do jogo Espacial EVE online trava computadores
Uma atualização lançada para o jogo RPG Espacial EVE online que deveria melhorar desempenho gráfico, causou o travamento de computadores com Windows XP. Isto porque os desenvolvedores atualizavam o arquivo "boot.ini" no computador do usuário (mesmo nome do arquivo que possui parâmetros de inicialização do Windows XP). O primeiro reinicio de sistema após a atualização travava o computador.
Microsoft Corp. corrigiu uma falha no software Excel 2007
que apresentava valores incorretos para cálculos envolvendo alguns
números, informou a empresa nesta quarta-feira (10/10). A companhia
ainda informou que vai incluir a correção no Windows Update, o quando
antes.
O bug, que a Microsoft reconheceu há duas semanas, mostra o número 100.000 como o resultado de cálculos que deveriam resultar em 65.535 ou em 65.536. O erro, segundo a Microsoft, não está nos cálculos do Excel, mas no código que carrega os valores resultantes e os formata antes de exibi-los em uma célula da planilha eletrônica. Somente a mais nova versão do programa, o Excel 2007, e seu equivalente online, o SharePoint 2007, contém esse bug.
As correções para a falha e a documentação no banco de dados de suporte da Microsoft, foram publicadas no site de downloads da companhia, com links disponíveis no blog do Excel. O downaloda para o Excel 2007 possui substanciais 32,5 Megabytes (MB).
"Estamos no processo de adicionar esta correção ao Microsoft Update para que ela seja atualizada automaticamente a usuários rodando o Excel 2007 ou o Excel Services 2007", informou David Gainer, gerente de projetos do programa, no blog da equipe.
A correção não está entre as correções liberadas no boletim mensal de atualizações anunciado ontem (09/10) pela Microsoft.
- See more at: http://idgnow.com.br/seguranca/2007/10/10/idgnoticia.2007-10-10.9822776538/#sthash.3uYGZqTy.dpuf
O bug, que a Microsoft reconheceu há duas semanas, mostra o número 100.000 como o resultado de cálculos que deveriam resultar em 65.535 ou em 65.536. O erro, segundo a Microsoft, não está nos cálculos do Excel, mas no código que carrega os valores resultantes e os formata antes de exibi-los em uma célula da planilha eletrônica. Somente a mais nova versão do programa, o Excel 2007, e seu equivalente online, o SharePoint 2007, contém esse bug.
As correções para a falha e a documentação no banco de dados de suporte da Microsoft, foram publicadas no site de downloads da companhia, com links disponíveis no blog do Excel. O downaloda para o Excel 2007 possui substanciais 32,5 Megabytes (MB).
"Estamos no processo de adicionar esta correção ao Microsoft Update para que ela seja atualizada automaticamente a usuários rodando o Excel 2007 ou o Excel Services 2007", informou David Gainer, gerente de projetos do programa, no blog da equipe.
A correção não está entre as correções liberadas no boletim mensal de atualizações anunciado ontem (09/10) pela Microsoft.
- See more at: http://idgnow.com.br/seguranca/2007/10/10/idgnoticia.2007-10-10.9822776538/#sthash.3uYGZqTy.dpuf
A Microsoft Corp. corrigiu uma falha no software Excel 2007
que apresentava valores incorretos para cálculos envolvendo alguns
números, informou a empresa nesta quarta-feira (10/10). A companhia
ainda informou que vai incluir a correção no Windows Update, o quando
antes.
O bug, que a Microsoft reconheceu há duas semanas, mostra o número 100.000 como o resultado de cálculos que deveriam resultar em 65.535 ou em 65.536. O erro, segundo a Microsoft, não está nos cálculos do Excel, mas no código que carrega os valores resultantes e os formata antes de exibi-los em uma célula da planilha eletrônica. Somente a mais nova versão do programa, o Excel 2007, e seu equivalente online, o SharePoint 2007, contém esse bug.
As correções para a falha e a documentação no banco de dados de suporte da Microsoft, foram publicadas no site de downloads da companhia, com links disponíveis no blog do Excel. O downaloda para o Excel 2007 possui substanciais 32,5 Megabytes (MB).
"Estamos no processo de adicionar esta correção ao Microsoft Update para que ela seja atualizada automaticamente a usuários rodando o Excel 2007 ou o Excel Services 2007", informou David Gainer, gerente de projetos do programa, no blog da equipe.
A correção não está entre as correções liberadas no boletim mensal de atualizações anunciado ontem (09/10) pela Microsoft.
- See more at: http://idgnow.com.br/seguranca/2007/10/10/idgnoticia.2007-10-10.9822776538/#sthash.3uYGZqTy.dpuf
O bug, que a Microsoft reconheceu há duas semanas, mostra o número 100.000 como o resultado de cálculos que deveriam resultar em 65.535 ou em 65.536. O erro, segundo a Microsoft, não está nos cálculos do Excel, mas no código que carrega os valores resultantes e os formata antes de exibi-los em uma célula da planilha eletrônica. Somente a mais nova versão do programa, o Excel 2007, e seu equivalente online, o SharePoint 2007, contém esse bug.
As correções para a falha e a documentação no banco de dados de suporte da Microsoft, foram publicadas no site de downloads da companhia, com links disponíveis no blog do Excel. O downaloda para o Excel 2007 possui substanciais 32,5 Megabytes (MB).
"Estamos no processo de adicionar esta correção ao Microsoft Update para que ela seja atualizada automaticamente a usuários rodando o Excel 2007 ou o Excel Services 2007", informou David Gainer, gerente de projetos do programa, no blog da equipe.
A correção não está entre as correções liberadas no boletim mensal de atualizações anunciado ontem (09/10) pela Microsoft.
- See more at: http://idgnow.com.br/seguranca/2007/10/10/idgnoticia.2007-10-10.9822776538/#sthash.3uYGZqTy.dpuf
2010 - Erros em terminais do Bank of Queensland na Austrália
Um erro no código do terminal pagador do Bank of Queensland, na Austrália, deixou diversos dispositivos inoperantes por uma semana. Aparentemente o problema aconteceu devido a uma rotina incorreta na conversão de um número hexadecimal. Quando o dispositivo devia assinalar 2010 ele pulava 6 anos até 2016, fazendo com que os terminais recusassem os cartões dos clientes por estarem expirados.
E veja que não foram citadas aqui, falhas de segurança, apenas casos de falhas de programas que ganharam notoriedade em função dos seus efeitos desastrosos.
A infeliz realidade é que erros de software como esses estão em todo lugar mas têm pouca repercussão caso seus efeitos não sejam tão devastadores. Se a planilha eletrônica travar enquanto você está alterando informações dos seus gastos pessoais ninguém morrerá por isso e, convenhamos, se os usuários não reclamarem do problema, certamente a fabricante não terá motivação para corrigi-lo se isso não resultar num ganho financeiro. Mas a
partir do momento que softwares cada vez mais complexos começam a
invadir sistemas críticos (sistemas para evitar acidentes em veículos
automotivos, decolagem e aterrissagem de aeronaves, plantas de controle
nuclear, etc) é possível que vejamos mais falhas como essas acontecendo. Diariamente a imprensa especializada divulga casos de crackers que
invadem sistemas devido as suas falhas de segurança (boa parte em função de códigos vulneráveis) mas nossa passividade em cobrar softwares de maior qualidade dos fabricantes, não são lá motivadores para que eles se empenhem mais nessa tarefa (apenas para registro, nos casos de falha de segurança também é preciso computar os casos de má implementação ou uso).
Vemos que as empresas deixam muito a desejar quando o assunto é teste dos seus produtos. Por um lado é até compreensível pois ninguém conseguirá testar todas as possibilidades com todas as variáveis que o mundo real oferece. Um problema que foi encontrado utilizando o software num determinado ambiente pode não acontecer em outro de característica similar, pois uma variável diferente, mesmo que ínfima, pode estar envolvida e desencadear toda uma gama diferente de resultados. O problema começa quando uma empresa sabe que o software possui determinadas vulnerabilidades e o comercializa assim mesmo. Como saber quais programas são esses? Como confiar nesse tipo de programa?
A confiança se torna um problema mais crítico ainda por que as falhas que são utilizadas para quebrar a segurança, geralmente não afetam a performance do produto. Falhas que afetam a performance de um software ou de um dispositivo são rapidamente notadas e demandam correções urgentes. Porém uma falha de segurança pode permanecer num produto durante anos e não ser descoberta (o que não impede que ela seja explorada por alguém que já a tenha encontrado) e por isso são deixadas pra segundo plano, mesmo que seus efeitos sejam devastadores. Este é um desafio muito grande e que torna a segurança mais difícil (e importante) do que a confiança. Quem "confia", sente-se "seguro", certo? Confiança é você acreditar que, quando o controle anticolisão do veículo falhar, ele
voltará a funcionar como um veículo antigo lhe devolvendo o controle, e não que ele se espatife na
próxima árvore que encontrar no caminho a 200 km/h. Se você não se sente seguro, dificilmente ativará essa funcionalidade do veículo, pois não há confiança. Confiança é você acreditar que se por algum motivo o braço mecânico do robô que está fazendo sua cirurgia falhar, ele será tranquilamente removido por um elemento humano, antes que decida brincar de jogo da velha com algum órgão interno seu. Mas como confiar nesses sistemas com tantos casos de dispositivos que negligenciaram a segurança no passado e que continuam negligenciando ainda hoje? Com códigos tão mal escritos? Sabendo que tratam-se de softwares extremamente complexos que rodam em rede? Como vamos esperar
que aplicações melhores sejam desenvolvidas, se nos acostumamos com pior, se nos acostumamos a reiniciar o computador quando algo dá errado e está tudo bem?
Conforme Bruce Schneier na sua apresentação para a Black Hat uma
das soluções para os problemas de segurança passa por fazer códigos
mais simples, pois quanto mais complexo for o código do programa, mais
falhas ele terá. A fórmula na verdade é bem simples:
- Mais complexidade -> Mais código -> Mais erros
- Mais erros -> mais vulnerabilidades de segurança (conhecidas ou não)
Mas o que estamos vendo vai justamente na contramão desse processo. Os códigos estão cada vez mais complexos e cheios de funcionalidades (algumas bem inúteis ou que nunca serão utilizadas) e a responsabilização dos fabricantes cada vez mais ignorada. Afinal, todo software possui erros, certo? Enquanto os fabricantes dos produtos não forem chamados às suas responsabilidades com mais rigor, não criarem códigos mais simples e com testes mais exaustivos, creio que continuaremos vivendo essa assincronia entre confiança e segurança, pois estamos confiando cada vez mais em softwares e a sensação de segurança é cada vez menor.
Você confia? E se sente seguro? Novamente, queria ser como você. Afinal, "Errar é humano, mas para estragar tudo mesmo é preciso um computador" - Paul Ehrlich (Biologista americano). E lendo essa frase, o pensamento que me vêm a cabeça é: "E não é que é verdade?" ;o)
Fontes de pesquisa sobre bugs históricos:
t+
Cristiano
"A grandeza não consiste em receber honras, mas em merecê-las." - Aristóteles
Nenhum comentário:
Postar um comentário