quarta-feira, 8 de outubro de 2014

Contraponto 14.980 - "As dúvidas no sistema de apuração do TSE"

.

08/10/2014

As dúvidas no sistema de apuração do TSE

 
 
 
 
Em Observação - Atualizado às 22:02

Recebi o e-mail abaixo. Publico devido à riqueza de detalhes e à dificuldade de conferir os dados apresentados. Por tudo isso, deve ser lido com ressalvas.


De Ivan Union

(Nassif, nao só o texto eh apocrifo como repete quase identicamente uma narrativa de aproximadamente 40 anos atraz, dos primordios da era dos computadores.  Nao vou achar a referencia tao cedo, sinto muito.)

De um leitor

Caro Nassif,

Escrevo esta mensagem anonimamente, por razões que ficarão claras a seguir.

Fui contratado pelo TSE e meu primeiro projeto foi tentar resolver um problema no código de um ex-funcionário.

O problema existia há alguns anos; era intermitente, difícil de ser replicado (e corrigido). Várias pessoas haviam tentado corrigi-lo antes de mim.

Antes de continuar, quero deixar claro que o TSE tem engenheiros extremamente capacitados. O fato é que nem mesmo as empresas mais ricas do mundo, como a Apple, o Google e a Microsoft, conseguem escrever código 100% correto. Ano após ano surgem falhas graves de segurança no Windows, no iOS, no Android, no Linux... nenhum, absolutamente nenhum software está imune a falhas.

Mas o TSE exerce uma tremenda pressão, de cima para baixo, para que os problemas não sejam divulgados. É interesse do TSE vender a idéia de que o nosso sistema é "o mais seguro do mundo". Quem julga isso? O próprio TSE. Não os engenheiros, é claro. 

Como funcionário recém contratado pelo TSE, fui obrigado a assinar um acordo de não divulgação sobre meu trabalho. Este é apenas mais um sintoma da dependência do segredo para que as falhas não sejam vistas. Mas a segurança de um sistema não deveria jamais depender do segredo sobre sua implementação e componentes. ("System security should not depend on the secrecy of the implementation or its components." [http://csrc.nist.gov/publications/nistpubs/800-123/SP800-123.pdf])

Mas voltando ao problema que eu deveria resolver.

Sentei-me no computador e comecei a estudar o código. Era um programa em C, dividido em 15 arquivos, sem espaçamento, com nomes de variáveis cripticos. Escrito para ser difícil de decifrar. Comecei por reformatar o código, para que eu pudesse compreender o que acontecia.

Depois de algumas horas de trabalho, consegui reproduzir o erro. Depois disso, pude rastreá-lo. E assim cheguei à origem -- uma pequena correção, e o problema estava resolvido. Ou deveria.

Compilei o código, esperando ver o problema ir embora. Mas quando eu executei o teste... o mesmo erro!

Verifiquei o código, e, acreditem se quiser, ele havia voltado ao estado inicial: 15 arquivos, sem espaçamento, com nomes de variáveis cripticos. Quis me matar por não ter feito uma cópia de minhas alterações. Voltei a reformatar o código, mas desta vez fiz uma cópia de segurança. Compilei. Tudo parecia ok. Executei o programa. E lá estavam, 15 arquivos, e o erro novamente.

Cheguei à conclusão de que em algum lugar do disco haveria uma cópia dos arquivos originais, e um programa os colocaria de volta quando você compilasse. Rastreei o disco inteiro, e nada. Talvez as strings estivessem criptografadas. Para isso, teria que percorrer todos os headers,  #include por #include, e assim sucessivamente.

Depois de vasculhar todo o código, não encontrei o que procurava. Isso só podia significar uma coisa: ele estava compilado numa biblioteca. Decido então recompilar todas as bibliotecas, afinal nós temos o código-fonte.

Feito isso, e sabendo que todas as bibliotecas estão limpas, volto a compilar e executar. Resultado: 15 arquivos embaralhados e o erro continua.

Era como mágica. Eu investiguei tudo, linha a linha, e podia garantir que o código malicioso não estava no código fonte. Mas ele está lá. Comecei a considerar a hipótese de desistir, e simplesmente reescrever o programa do zero. Isto definitivamente seria mais fácil. Mas alguma coisa estava muito errada, eu não podia desistir. Passei mais de uma semana estudando o código-fonte, até que decidi analisar o código de máquina.

Aí então caiu a ficha: era o compilador. Toda vez que eu recompilava o código, o compilador injetava o código malicioso, gerando um executável contaminado.

Fui olhar no código do compilador e, de fato, ele havia sido modificado para interceptar o código fonte daquele programa, gerar os 15 arquivos e compilá-los, ao invés do programa original.

No final, descobrimos uma outra falha: se recompilássemos /sbin/login ele colocaria uma backdoor que permitiria a qualquer um que usasse uma senha específica entrar no sistema como usuário root.

Esta foi uma falha grave, que permaneceu oculta durante anos. O que foi feito durante este período? Quantos outros problemas poderão existir?

________________________________

PITACO DO ContrapontoPIG 

Tipo Proconsult?
________________________________
.

Um comentário :

  1. É um jeito de admitirem que as urnas estão viciadas a votar nas mesmas pessoas nas quais manipuladas adequadamente para cada finalidades, no caso os candidatos tucanos estão e toda a bandidagem da politica foram eleito, porque mesmo depois de digitar nomes das pessoas a imagem já vem criptografadas na tela!!

    ResponderExcluir

Veja aqui o que não aparece no PIG - Partido da Imprensa Golpista