A Oracle está na água quente esta semana em um post no blog escrito por sua chefe de segurança, Mary Davidson. A publicação, embora abranja vários tópicos, é principalmente sobre a prática de relatar possíveis vulnerabilidades de segurança ao Oracle. Especificamente, por que você não deveria.
“Recentemente, tenho visto um grande aumento nos clientes fazendo engenharia reversa de nosso código para tentar encontrar vulnerabilidades de segurança nele. É por isso que venho escrevendo muitas cartas para os clientes que começam com “oi, howzit, aloha”, mas terminam com “por favor, cumpra seu contrato de licença e pare de fazer engenharia reversa do nosso código, já”.
Davidson explica que há um número crescente de clientes preocupados com a segurança que estão fazendo engenharia reversa de software da Oracle em busca de vulnerabilidades de segurança (ou contratando consultores para fazer isso por eles). Davidson acusa esses clientes de violar seus contratos de licença, de não tomarem precauções de segurança mundanas, de tentar fazer o trabalho da Oracle por eles e de geralmente serem pessoas ruins. Se o cliente encontrou uma vulnerabilidade real, enquanto a Oracle irá consertá-lo.
“Quase detesto responder a essa pergunta porque quero reiterar que os clientes não devem e não devem fazer engenharia reversa de nosso código. […] Não daremos a um cliente que relate esse problema (que descobriu por meio de engenharia reversa) um patch especial (único) para o problema. Também não forneceremos crédito em nenhum aviso que possamos emitir. Você não pode realmente esperar que digamos "obrigado por quebrar o contrato de licença".
Isso não ocorreu bem na comunidade de segurança, e o post foi rapidamente removido - embora não antes de gerar uma nova hashtag Hashtag Activism: #powerful ou #pointless? Hashtag Activism: #powerful ou #pointless? #BringBackOurGirls, #ICantBreathe e #BlackLivesMatter tiveram ampla cobertura internacional no ano passado - mas as hashtags são um meio eficaz de ativismo? Consulte Mais informação .
"Verifique primeiro o EULA da Enigma", disse Alan Turing. #oraclefanfic
- Thorsten Sick (@ThorstenSick) 11 de agosto de 2015
Mas, se você não estiver familiarizado com o mundo da segurança, pode não ser óbvio porque o post original é tão equivocado. Então, hoje, vamos falar sobre onde a filosofia de segurança da Oracle se afasta do mainstream e por que é um problema.
Explicando a controvérsia
Então, o que exatamente é engenharia reversa e por que Davidson está tão preocupado com isso? Basicamente, quando a Oracle lança um software, eles “compilam” seus códigos-fonte internos em arquivos executáveis e entregam esses arquivos aos clientes. Compilação é um processo que traduz código legível em humanos (em linguagens como C ++ 3 Websites Para Começar a Aprender com a Aprendizagem C ++ Programming Language 3 Websites Para Começar a Aprender C ++ Linguagem de Programação Aprender a programar pode ser difícil para muitos, mesmo com linguagens de programação relativamente fáceis Enquanto Java é mais fácil de começar (onde temos vários artigos aqui em MakeUseOf para Java, bem como ... Leia mais) em uma linguagem binária mais densa que pode ser alimentada diretamente em um processador de computador.
O código-fonte da Oracle não é público. Isso tem o objetivo de dificultar que outros roubem sua propriedade intelectual. No entanto, isso também significa que é muito difícil para os clientes verificar se o código é seguro. É aqui que entra a descompilação. Basicamente, a decomposição se traduz em outra direção, convertendo os arquivos executáveis de volta em código legível por humanos. Isso não entrega exatamente o código-fonte original, mas fornece código que funciona da mesma maneira - embora seja difícil ler, devido à perda de comentários e estrutura organizacional.
Esta é a "engenharia reversa" a que Davidson se refere. A Oracle é contra isso porque acha que isso coloca em risco sua propriedade intelectual. Isso é pelo menos um pouco tolo, porque usar um contrato de licença para proibir o roubo de IP é um pouco como usar um capacho com palavras severas para evitar a invasão de casas. Os tipos de pessoas que tentarão clonar seus produtos não se importam com contratos de licença 4 maneiras de ler e entender um contrato de licença de usuário final (EULA) Mais facilmente 4 maneiras de ler e entender um contrato de licença de usuário final (EULA) Mais facilmente EULAs, ou contratos de licença de usuário final, são um dos males da vida moderna. Estes são acordos infinitamente verbosos, geralmente escritos em letras minúsculas. Estas são as coisas que você rola para baixo, procurando por algo mais ... e muitas vezes não estão em jurisdições onde você poderia impor esses acordos em qualquer caso.
A humanidade está condenada… #oraclefanfic #justoraclethings pic.twitter.com/e6MOZzkkvq
- CyberAnarchist (@ Cyb3rOps) 12 de agosto de 2015
A política realmente afeta apenas clientes legítimos. A situação é semelhante à do videogame DRM 6 lugares para comprar jogos sem DRM [MUO Gaming] 6 lugares para comprar jogos livres de DRM [MUO Gaming] Como eu decidi não comprar jogos do Steam, preciso encontrar outros fontes. Muitos deles são realmente piores do que o próprio Steam. A loja da Ubisoft é desconcertante e cheia de DRM irritante. Arte Eletrônica ... Leia Mais, mas de alguma forma ainda mais ineficaz.
Por que os clientes querem descompilar esses executáveis? É tudo sobre segurança. Ter acesso ao código-fonte permite que você busque por bugs e possíveis problemas. Frequentemente, isso é feito usando um software que executa uma “análise de código estático” - uma leitura automatizada do código, que identifica bugs conhecidos e práticas de software perigosas que tendem a levar a bugs. Embora existam ferramentas que analisam diretamente o arquivo executável, a descompactação permite análises mais profundas. Esse tipo de análise estática é uma ferramenta padrão do comércio de segurança e a maioria das empresas preocupadas com a segurança usa esse software internamente para produzir código com menor probabilidade de conter sérios erros.
A política da Oracle nesse tipo de análise é simplesmente "não". Por quê? Vou deixar Davidson explicar.
“Um cliente não pode analisar o código para ver se existe um controle que impeça o ataque da ferramenta de varredura (o que provavelmente é um falso positivo) [...] Agora, devo observar que não aceitamos apenas faça a varredura de relatórios como "prova de que existe um ali, ali", em parte porque, quer você esteja falando em análise estática ou dinâmica, um relatório de varredura não é uma prova de uma vulnerabilidade real. […] Oh, e exigimos que os clientes / consultores destruam os resultados de tal engenharia reversa e confirmem que o fizeram. ”
Em outras palavras, a ferramenta transformando um resultado não é a prova de um bug real - e, como a Oracle usa essas ferramentas internamente, não há sentido em clientes executá-las por conta própria.
O grande problema com isso é que essas ferramentas de análise de código estático não existem apenas para chamar a atenção para os erros. Eles também devem servir como alvo para a qualidade e segurança do código. Se você despejar a base de código da Oracle em uma ferramenta de análise estática padrão do setor e ela emitir centenas de páginas de problemas, isso é um péssimo sinal.
A resposta correta, quando uma ferramenta de análise de código estática retrocede um problema, não é olhar para o problema e dizer "ah, não, isso não causa um bug porque tal e tal". A resposta correta é entrar e corrigir o problema. As coisas marcadas por ferramentas de análise de código estático são geralmente práticas ruins em geral, e sua capacidade de determinar se um determinado problema realmente causa um bug é falível. Ao longo de milhares de problemas, você vai perder o material. Você é melhor não ter essas coisas em sua base de código, em primeiro lugar.
Aqui está o Oculus CTO John Carmack cantando louvores a essas ferramentas de seu tempo na iD Software. (Sério, leia todo o ensaio, é interessante).
“Tivemos um período em que um dos projetos acidentalmente desativou a opção de análise estática por alguns meses e, quando percebi e reativei, havia pilhas de novos erros que haviam sido introduzidos nesse ínterim. […] Estas foram demonstrações de que as operações normais de desenvolvimento estavam continuamente produzindo essas classes de erros, e [análise de código estático] estava efetivamente nos protegendo de muitos deles. ”
Em resumo, é provável que muitos dos clientes da Oracle não estivessem necessariamente tentando relatar bugs específicos - eles estavam perguntando por que as práticas de codificação da Oracle eram tão ruins que sua base de código estava repleta de milhares e milhares de problemas tão básicos que poderiam ser escolhidos. por software automatizado.
Eu ainda estou triste que o sol se foi. E quem foi o gênio que os vendeu para a Oracle? É como deixar Darth Vader tomar conta de seus filhos.
- Brad Neuberg (@bradneuberg) 15 de agosto de 2015
Segurança por etiquetas
Então, o que os clientes preocupados com segurança devem fazer, em vez de usar ferramentas de análise estática? Felizmente, o post do blog de Davidson foi extremamente detalhado sobre esse assunto. Além de advogar práticas gerais de segurança básica, ela faz sugestões concretas para aqueles preocupados com a segurança do software que eles usam.
“Há muitas coisas que um cliente pode fazer, por exemplo, conversando com fornecedores sobre seus programas de garantia ou verificando certificações de produtos para os quais há selos Good Housekeeping (ou selos de" código bom ") como Common Criteria. certificações ou certificações FIPS-140. A maioria dos fornecedores - pelo menos, a maioria dos grandes que eu conheço - tem programas de garantia bastante robustos agora (sabemos disso porque todos comparamos notas em conferências) ”.
Esta é uma resposta horripilante de uma organização tão grande quanto a Oracle. A segurança de computadores é um campo em rápida evolução. Novas vulnerabilidades são encontradas o tempo todo, e formalizar os requisitos de segurança em uma certificação que é atualizada a cada poucos anos é um absurdo. Segurança não é um adesivo. Se você acredita que um software crucial é seguro com base em um selo na embalagem, você está sendo irresponsavelmente estúpido.
As ferramentas de análise estática são atualizadas com muito mais frequência do que essas certificações - em alguns casos, diariamente - e a eliminação de todos os problemas que elas geram ainda não é suficiente para ter muita confiança na segurança de seu código, porque a maioria das vulnerabilidades também complexo a ser detectado por esses tipos de ferramentas automatizadas.
A única maneira de ter confiança na sua própria segurança é expor seu código ao mundo e pedir que os hackers tentem quebrá-lo. É assim que a maioria das principais empresas de software opera: se você encontrar um problema com o código delas, elas não ficarão condescendentemente irritadas com você por violar seu contrato de uso. Eles te pagam dinheiro. Eles querem que as pessoas tentem ao máximo quebrar o software o tempo todo. É a única maneira de ter certeza de que seu código está seguro.
Esses programas são chamados de programas “bug bounty”, e são a melhor coisa a acontecer com a segurança em nível corporativo em um longo período de tempo. Eles também são, coincidentemente, algo sobre o qual Davidson tem opiniões bastante fortes.
“Bounties de bugs são a nova boy band (bem aliterativa, não?) Muitas empresas estão gritando, desmaiando e jogando roupas íntimas em pesquisadores de segurança […] para encontrar problemas em seu código e insistindo que This Is The Way, Walk In It: if você não está fazendo recompensas de bugs, seu código não é seguro.
Ah, bem, nós mesmos encontramos 87% de vulnerabilidades de segurança, os pesquisadores de segurança encontram cerca de 3% e os demais são encontrados pelos clientes. […] Eu não estou descontando recompensas de bugs, apenas observando que, em uma base estritamente econômica, por que eu jogaria muito dinheiro em 3% do problema? ”
Para começar, com base nos resultados dessas análises de código estático, pode se tornar muito mais do que 3% se você os pagou. Mas eu divago. O ponto real é este: bounties bug não são para você, eles são para nós. Você poderia encontrar bugs de forma mais eficiente se gastasse o mesmo dinheiro com especialistas em segurança interna? Bem, provavelmente não - mas vamos jogar o Oracle um osso e assumir que eles poderiam. No entanto, eles também poderiam pegar o dinheiro, depositá-lo e, então, não fazer absolutamente nada. Se a segurança resultante é insignificante, os clientes só vão descobrir sobre isso daqui a alguns anos quando seus números de segurança social misteriosamente acabam na deep web Como encontrar sites de cebola ativa e por que você pode querer como encontrar sites de cebola ativa e Por que você pode querer Sites da Onion, assim chamados porque terminam com ".onion", são hospedados como serviços ocultos do Tor - uma maneira completamente anônima de hospedar sites. Consulte Mais informação .
"Não há vulnerabilidade. O EULA diz isso." #oraclefanfic pic.twitter.com/cUfafDCWbv
- Schuyler St. Leger (@DocProfSky) 11 de agosto de 2015
As recompensas de bugs existem pela metade, porque são uma maneira genuinamente eficaz de identificar bugs, e metade porque são uma forma de segurança que você não pode falsificar. Uma recompensa de bug credivelmente diz ao mundo que quaisquer erros deixados no código são mais caros para encontrar do que a recompensa declarada.
Não existem bênçãos para sua conveniência, Oracle, porque eles não confiam em você.
Nem devemos nós! Muitas grandes empresas permitem que a segurança caia no esquecimento, como os numerosos megabreaches Alvo confirma até 40 milhões de clientes dos EUA Cartões de crédito potencialmente alvo Hacked confirma até 40 milhões de clientes dos EUA Cartões de crédito potencialmente hackeados Alvo acaba de confirmar que um hack poderia ter comprometido as informações do cartão de crédito para até 40 milhões de clientes que fizeram compras em suas lojas nos EUA entre 27 de novembro e 15 de dezembro de 2013. Leia Mais mostra tudo com muita clareza. Você é o segundo maior fabricante de software do mundo. É um absurdo pedir que aceitemos sua palavra de que seus produtos são seguros.
O que Davidson fica bem
Para ser justo com Davidson, há elementos disso que são razoáveis no contexto. Provavelmente, muitos de seus clientes embarcam em auditorias ambiciosas do código da Oracle, sem gastar tempo para eliminar problemas de segurança mais mundanos de seus sistemas.
“Ameaças persistentes avançadas” - organizações habilidosas de hackers que tentam obter acesso a organizações específicas para roubar dados - são certamente assustadoras, mas pelos números elas são muito menos perigosas do que os milhões de hackers amadores oportunistas com ferramentas automatizadas. Fazer esse tipo de análise estática de software comercial quando você não adotou medidas básicas de segurança é muito parecido com a instalação de uma sala de pânico quando você ainda não tem uma fechadura na porta da frente.
Da mesma forma, provavelmente é frustrante e inútil receber a mesma análise automatizada de novo e de novo e de novo.
No entanto, como um todo, o artigo revela algumas idéias seriamente desatualizadas sobre segurança do sistema e o relacionamento entre desenvolvedores e clientes. Compreendo que o trabalho de Davidson é frustrante, mas os usuários que fazem o possível para verificar a segurança do software que usam não são o problema. Aqui está o presidente da Security Awareness, Ira Winkler:
“A Oracle é uma empresa muito grande e rica, com produtos amplamente distribuídos e usados para aplicativos críticos. Período. Eles têm a responsabilidade de tornar seu software o mais forte possível [...] Pode haver muitos falsos positivos e custos associados, mas isso é um fator de [vender] muitos softwares que têm muitos usuários. É um custo de fazer negócios. Tenho certeza de que todas as empresas de software têm os mesmos relatórios de falsos positivos. Eu não ouço a Microsoft et al. reclamando. ”
Se a Oracle não quiser continuar recebendo milhares de problemas encontrados por ferramentas de segurança estática, talvez eles devam corrigir esses milhares de problemas. Se eles estão incomodados com pessoas que usam os mesmos não-bugs repetidas vezes, talvez eles devam ter um programa de recompensas de bug apropriado que tenha mecanismos para lidar com repetidas submissões de não-problemas. Os clientes da Oracle clamam por um padrão mais alto de segurança, e envergonhá-los porque não é a resposta correta.
Mesmo que a Oracle tenha derrubado e, em geral, tenha desmentido o post, ele foi escrito e revela uma cultura de segurança profundamente equivocada no Oracle. A abordagem de segurança da Oracle prioriza a proteção de sua própria propriedade intelectual sobre a segurança e tranquilidade de seus clientes - e se você confiar o software Oracle a informações críticas, isso deve assustá-lo.
O que você acha? Você está preocupado com a filosofia de segurança da Oracle? Você acha que Davidson está sendo tratado com muita severidade? Deixe-nos saber nos comentários!