Recentemente, tive uma dessas discussões apaixonadas sobre desenvolvimento aberto – das quais já não costumo mais ter paciência para participar. Aprendi com o tempo que a área de tecnologia não deve ser movida por paixões, mas por decisões práticas e objetivas, que levem em consideração o ambiente ao redor. E partindo desse princípio, pode-se dizer que a grande maioria das técnicas e tecnologias é aplicável.
Imagem: slashgear.com
Desenvolvimento aberto (código aberto e software livre são utilizados popularmente como sinônimos, o que não exatamente apropriado) é uma forma de desenvolvimento de software, nada mais. Nem é preciso entrar nos meandros da discussão, porque ela agrega muito pouco no quesito segurança e nada, nos paradigmas fundamentais da programação.
O desafio atual da segurança no desenvolvimento reside naquela clássica questão de se saber o que realmente um código está fazendo (por exemplo, se ele está ou não em looping), um problema sem solução.
Hoje, temos ferramentas que “fiscalizam” as melhores práticas de programação, capazes de detectar, em tempo real, um bom nível de erros de codificação. Mas no que diz respeito ao problema apresentado, são incompletas em sua funcionalidade. No final das contas, pressupõe-se que a intervenção humana ainda é necessária.
O principal argumento da suposta segurança dos sistemas abertos baseia-se na abertura e na visualização do código por milhões de pessoas. A alegação apresenta um componente de obviedade tentador. Afinal, algo visto e validado por milhões de pessoas deve ser mais seguro do que aquilo que ficou restrito a duas ou três. Mas a realidade é outra.
O código aberto não é nenhuma novidade, existe há muito tempo. Um exemplo clássico foi o bug da pilha TCP/IP que atingiu 100% dos Sistemas Operacionais, há mais de 10 anos. Ou seja, todos os fornecedores tinham o mesmo bug. Isso significa que utilizaram o mesmo código, fatalmente derivado de um BSD, que era aberto, livre para uso.
Ainda que o código tenha sido visto por milhões de pessoas de diferentes corporações, o bug existiu por muito tempo. Então, por que, ao olharem para o código, não viram o bug?
Muitas pessoas confundem a velocidade na correção de um problema de segurança com a inexistência dele. Um grande equívoco! Já que a agilidade em corrigi-lo está vinculada diretamente ao compromisso do fornecedor em fazê-lo, seja ele aberto ou fechado.
Assim, conclui-se que o sistema não está livre de problemas de segurança, já que os fornecedores, abertos ou fechados, têm esses mecanismos de fornecimento.
Então, onde estão os analistas de código? Por que o código aberto não é mais seguro?
Se oferecesse maior segurança, o software livre (baseado em desenvolvimento aberto) não teria bugs. Todos podem visualizar o código, entretanto 99,9999% dos bugs são descobertos em tempo de execução na maioria dos sistemas, e não com análise de código.
Analisar o código, aliás, é algo mais complexo do que desenvolver o próprio código. Não existe um processo de automação que diga o que um código está fazendo. Além disso, já se tem poucas pessoas desenvolvendo código em comparação às pessoas que usam os produtos e, talvez, praticamente ninguém verificando.
Podemos até fazer uma analogia com os processos de compra do Governo. Todos eles são públicos e estão disponíveis para a população verificar. Nem por isso o número de problemas apresentados na televisão em relação a esses procedimentos diminui. A população em geral que tem acesso a tais processos não tem capacidade de avaliá-los, apesar de pagar por eles e usufruir de seu resultado.
Para piorar (no que diz respeito à segurança), temos as bibliotecas de terceiros, amplamente usadas, as BIOS de computador e os sistemas de apoio embarcados para processamentos especializados (FPGA, por exemplo). Todos, livres ou não, com possibilidades de backdoors. O mercado sempre foi colaborativo, não se esqueçam desse ponto. Bibliotecas, integrações e compartilhamento de código entre sistemas sempre existiram. Todas essas camadas de apoio, que são ligadas à execução de um sistema, podem esconder brechas de segurança.
Quantas vezes você, leitor, verificou o código aberto de alguma aplicação para ver se existe algo suspeito nele? Será que este “IF” esconde um backdoor? Quantas pessoas você conhece que já fizeram isso? Eu não me lembro de nenhuma nos últimos 15 anos – pelo menos que tenha descoberto algo relevante. Conheci muita gente que o fez para corrigir um problema ou aprender como se faz algo, mas nunca para tirar conclusões sobre aspectos de segurança ou corretude do sistema.
Como se já não bastasse a dificuldade técnica na avaliação de um código feito por outra pessoa (em ambientes de desenvolvimento essa é uma reclamação constante de novos programadores que entram na equipe), ainda existe a possibilidade de estarem escondidas entre os códigos, ações não tão óbvias.
Lembro de um campeonato que existia na época de faculdade, cujo objetivo era desenvolver um programa em C que parecia fazer algo específico, mas, na verdade, escondia outras operações. Havia também uma competição que premiava o programa em C mais “confuso”, de modo que, ao ser lido, o leitor não pudesse saber o que ele fazia. Um dos requisitos desses campeonatos era que o programa fosse pequeno, capaz de ser analisado por uma pessoa.
Se é possível esconder códigos em programas pequenos, pense agora no volume de códigos existentes atualmente!
Um backdoor pode ser apenas uma atribuição errônea de uma variável ou um conjunto de 03 linhas de código, bem diferente de milhares de linhas de código, como ocorreu no FLAME.
Resiliência: Os backdoors vieram para ficar, sejam por erros de programação ou inserção proposital.
