Com dinheiro suficiente, todos os insetos são superficiais

Eric Raymond, em The Cathedral and the Bazaar (A Catedral e o Bazar), escreveu a famosa frase

Se o senhor tiver olhos suficientes, todos os bugs são superficiais.

A ideia é que o software de código aberto, em virtude de permitir que qualquer pessoa visualize o código-fonte, é inerentemente menos sujeito a bugs do que o software de código fechado. Ele chamou isso de “Lei de Linus”.

No que diz respeito a isso, acredito que seja verdade. Quando apenas os 10 programadores que trabalham na sua empresa hoje podem examinar sua base de código, é improvável que ela seja tão bem revisada quanto uma base de código que é pública para o escrutínio do mundo no GitHub.

No entanto, o Vulnerabilidade SSL Heartbleed foi o ponto de virada para a Lei de Linus, uma exploração catastrófica baseada em um grave bug em um software de código aberto. Quão catastrófico? Ela afetou cerca de 18% de todos os sites HTTPS do mundo e permitiu que os invasores visualizassem todo o tráfego desses sites, sem criptografia… por dois anos.

Todos aqueles sites que o senhor achava que eram seguros? Não. Essa falha passou despercebida por dois anos inteiros.

Dois anos!

OpenSSL, a biblioteca com esse bug, é uma das partes mais importantes da infraestrutura de Internet que o mundo tem – em que grandes empresas confiam para criptografar as informações privadas de seus clientes à medida que elas trafegam pela Internet. O OpenSSL foi usado em milhões de servidores e dispositivos para proteger o tipo de material importante que o senhor deseja criptografar e ocultar de olhos curiosos, como senhas, contas bancárias e informações de cartão de crédito.

Esse deve ser um dos códigos mais bem revisados do mundo. O que aconteceu com nossos olhos, senhor?

Na realidade, geralmente é muito, muito difícil corrigir bugs reais em qualquer coisa que não seja o software de código aberto mais trivial. Sei que raramente fiz isso, e sou um desenvolvedor experiente. Na maioria das vezes, o que realmente acontece é que o senhor informa o problema ao programador e espera para ver se ele o corrige. Neil Gunton

Mesmo que uma comunidade de hackers corajosos leia o código, não é muito provável que eles identifiquem um dos problemas difíceis de detectar. Por quê? Poucos hackers de código aberto são especialistas em segurança. – Jeremy Zawodny

O fato de muitos olhos estarem olhando para um software provavelmente não o tornará mais seguro. No entanto, é provável que faça com que as pessoas acreditem que ele é seguro. O resultado é uma comunidade de código-fonte aberto que provavelmente confia demais na segurança. – John Viega

Acho que há alguns problemas com a Lei de Linus:

0. Há uma grande diferença entre uso globos oculares e desenvolvimento eyeballs. O fato de o senhor baixar alguns binários em um RPM, ou compilar algo no Linux, ou até mesmo relatar erros aos desenvolvedores por meio do rastreador de erros, não significa que esteja fazendo algo para contribuir com a revisão do código subjacente. A maioria dos olhos está olhando para a parte externa do código, não para a parte interna. E, embora o senhor possa descobrir bugs, até mesmo bugs de segurança importantes, por meio do uso, os bugs de segurança mais graves exigem conhecimento interno de como o código funciona.

1. O ato de escrever (ou recortar e colar) seu próprio código é mais fácil do que entender e revisão por pares o código de outra pessoa. Há uma assimetria fundamental e inevitável de trabalho aqui. O volume de código que está sendo produzido atualmente – mesmo se o senhor presumir que apenas uma pequena fração dele é “importante” o suficiente para exigir uma revisão séria – supera em muito o número de olhos disponíveis para analisar o código. (Sim, esse é outro argumento a favor do escrever menos código.)

2. Não há número suficiente de qualificados para examinar o código. É claro que o número total de programadores está crescendo lentamente, mas que porcentagem desses programadores é suficientemente qualificada e tem o histórico de segurança correto para poder auditar o código de outra pessoa de forma eficaz? Uma pequena fração.

Mesmo que o código seja 100% de código-fonte aberto, totalmente essencial para a missão e usado por grandes empresas em praticamente todos os servidores da Web voltados para o público para fins de segurança do cliente, acabamos com bugs críticos que comprometem todos. Para dois anos!

Essa é a lição. Se nós não conseguirmos, naturalmente, atrair olhares suficientes para o OpenSSLcomo qualquer outro código tem alguma chance? O que devemos fazer? Como conseguimos mais olhos?

A resposta de curto prazo foi:

Essas são duas coisas muito boas e resultados necessários. Deveríamos estar fazendo isso para todas as partes essenciais do ecossistema de código aberto do qual as pessoas dependem.

Mas qual é a resposta de longo prazo para o problema geral da falta de olhares suficientes para o código-fonte aberto? É algo que soará muito familiar para o senhor, embora eu suspeite que Eric Raymond não ficará muito feliz com isso.

Dinheiro. Muito e muito dinheiro.

Cada vez mais, as empresas estão se voltando para programas comerciais de recompensa por bugs. Tanto os criados por eles mesmos quanto os executados por meio de serviços de terceiros, como Bugcrowd, Synack, HackerOnee Crowdcurity. Isso significa que o senhor paga por bug, com um pagamento maior quanto maior e mais grave for o bug.

Ou o senhor pode participar de um evento anual como o Pwn2Ownonde há um concurso anual e prêmios enormes, tão grandes quanto centenas de milhares de dólarespor explorar software comum. A realização de um grande evento anual significa muita publicidade e interesse, atraindo as maiores armas.

Essa é a mensagem. Se o senhor quiser encontrar bugs no seu código, no seu site, no seu aplicativo, faça isso da maneira antiga: pagando por eles. O senhor compra os olhos.

Embora eu aplauda qualquer esforço para tornar as coisas mais seguras, concordo plenamente que a segurança é uma batalha que devemos travar em várias frentes, tanto comerciais quanto não comerciais, não me agrada que alguns aspectos do pagamento por bugs se tornem o novo normal. O que estamos incentivando, exatamente?

O dinheiro faz com que os bugs de segurança se tornem clandestinos

Agora há um preço associado às explorações, e quanto mais profunda for a exploração e menos conhecida ela for, mais incentivo haverá para não contar a ninguém sobre ela até que o senhor possa receber um pagamento maior. Portanto, o senhor pode esperar até um ano para relatar qualquer coisa e, enquanto isso, esse bug de segurança está à solta – quem sabe quem mais poderá tê-lo descoberto até lá?

Se o foco do senhor é o pagamento, quem está pagando mais? Os mocinhos ou os bandidos? O senhor deve esperar mais tempo por um pagamento maior ou transformar a exploração em algo ainda maior? Espero que, para nosso bem, os mocinhos tenham os bolsos mais fundos, caso contrário, estaremos todos ferrados.

Gosto desse Google abordou algumas dessas preocupações ao tornar o Pwnium, sua variante específica para o Chrome do Pwn2Own, a) não mais um evento anual, mas o dia todo, todos os dias e b) aumentando o prêmio em dinheiro para “infinito”. Não sei se isso é suficiente, mas certamente está indo na direção certa.

O dinheiro transforma a segurança em uma meta “minha” em vez de uma meta “nossa”

Eu notei essa tendência pela primeira vez quando uma ou duas pessoas relataram pequenos bugs de segurança no Discourse e, em seguida, pareciam estender a mão, com expectativa. (Pelo menos, tanto quanto o senhor pode fazer algo assim por e-mail.) Parecia muito estranho e me deixou desconfortável.

Será que agora sou obrigado, além de fornecer um projeto de código aberto totalmente gratuito para o mundo, a pagar às pessoas por contribuírem com informações sobre bugs de segurança que tornam esse projeto de código aberto melhor? Acredite, fiquei muito grato pelos relatórios de bugs de segurança e enviei a eles tudo o que pude: adesivos, camisetas, e-mails de agradecimento efusivos, chamadas no código e check-ins. Mas o código-fonte aberto não deve ser pelo dinheiro… não é mesmo?

Talvez o cenário seja diferente para produtos comerciais de código fechado, em que não há expectativa de quid pro quo, e todos já pagam pelo serviço direta ou indiretamente de qualquer forma.

Sem dinheiro? Sem segurança.

Se todos os melhores pesquisadores de segurança estiverem trabalhando em recompensas por bugs cada vez maiores e todas as grandes empresas adotarem esses tipos de programas de recompensa por bugs, o que isso fará com o setor de software?

Isso implica que, a menos que o senhor tenha um grande orçamento, não pode esperar ter uma segurança excelente, porque ninguém vai querer relatar bugs de segurança para o senhor. Por que isso aconteceria? Eles não receberão um pagamento. Eles procurarão outro lugar.

Uma cultura de ransomware do tipo “pague-me ou não contarei ao senhor sobre sua terrível falha de segurança” também não parece muito distante. Já recebemos e-mails como esse.

Dinheiro fácil atrai todos os níveis de habilidade

Um efeito colateral infeliz dessa tendência de recompensa por bugs é que ela atrai não apenas programadores de boa-fé interessados em segurança, mas qualquer pessoa interessada em dinheiro fácil.

Recebemos muitos relatórios de bugs de segurança “sérios” que eram de valor extremamente baixo. E temos que acompanhá-los, porque são “sérios”, certo? Infelizmente, muitos deles são uma perda de tempo, porque …

• O remetente está mais interessado em assustá-lo com as implicações críticas e maciças de segurança desse bug do que em fornecer uma explicação decente sobre o bug, de modo que o senhor acabará fazendo todo o trabalho.

• O remetente não entende o que é e o que não é um exploit, mas sabe que há valor em qualquer coisa que se assemelhe ao um exploit e, portanto, envia tudo o que consegue encontrar.

• O remetente não pode compartilhar anotações com outros pesquisadores de segurança para verificar se o bug é de fato uma exploração, pois eles podem “roubar” sua exploração e serem pagos por ela antes que o façam.

• O remetente precisa convencê-lo de que se trata de uma exploração para ser pago, portanto, ele discutirá com o senhor sobre isso. Em resumo.

Os incentivos parecem realmente errados para mim. Por mais que eu saiba que a segurança é incrivelmente importante, vejo essas interações com uma sensação crescente de pavor porque elas geram trabalho para mim e os retornos são baixos.

O que podemos fazer?

Felizmente, todos nós temos o mesmo objetivo: tornar o software mais seguro.

Portanto, devemos ver os programas de recompensa por bugs como um ângulo de ataque adicional, outro aspecto da “defesa em profundidade”, talvez um pouco mais otimizado para projetos comerciais em que há muito dinheiro. E isso não tem problema.

Mas também tenho alguns conselhos para os programas de recompensa por bugs:

• O senhor deve ter alguém para examinar esses relatórios de bugs e certificar-se de que são confiáveis, têm etapas claras de reprodução e são repetíveis, antes mesmo de vê-los.

• O senhor deve criar incentivos adicionais em sua comunidade para algum tipo de trabalho colaborativo para obter explorações maiores e melhores. Esses pesquisadores precisam trabalhar juntos em público, não em segredo uns contra os outros.

• O senhor deve ter um sistema de reputação que se desenvolva de modo que somente os melhores e mais comprovados colaboradores consigam passar e enviar relatórios.

• Incentive as organizações maiores a financiar a caça a bugs para projetos comuns de código aberto, não apenas para seus próprios aplicativos e sites de código fechado. No Stack Exchange, fazemos doações para projetos de código aberto que usamos todos os anos. A doação de uma recompensa por bugs pode representar um grande aumento no número de visualizações desse código.

Estou preocupado com a possibilidade de estarmos caminhando lentamente para um mundo em que o com dinheiro suficiente, todos os bugs são superficiais. O dinheiro introduz, de fato, alguns incentivos perversos para a segurança de software, e esses incentivos devem ser observados com atenção.

Mas ainda acredito que as pessoas que relatam livremente bugs de segurança em software de código aberto porque

• É a coisa certa a fazer™.

e

• Eles querem contribuir com os projetos de código aberto que os ajudaram, e ao mundo

… esperamos que não desapareça tão cedo.

[advertisement] Como o(a) senhor(a) está exibindo o seu incrível? Crie um Perfil do Stack Overflow Careers e mostre todo o seu trabalho árduo no Stack Overflow, no Github e em praticamente todos os outros sites de codificação. Quem sabe, o senhor pode até ser recrutado para uma grande novo cargo!