.
08/10/2014
As dúvidas no sistema de apuração do TSE
Jornal GGN qua, 08/10/2014 - 20:00 Atualizado em 08/10/2014 - 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 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