Oracle est dans l'eau chaude cette semaine sur un billet de blog écrit par leur chef de la sécurité, Mary Davidson. La publication, bien qu'elle couvre un large éventail de sujets, concerne la plupart du temps la possibilité de signaler des vulnérabilités de sécurité à Oracle. Plus précisément, pourquoi vous ne devriez pas.
«Récemment, j'ai constaté une augmentation importante de la part des clients dans l'ingénierie inverse de notre code pour tenter de trouver des failles de sécurité. C'est pourquoi j'ai écrit beaucoup de lettres aux clients qui commencent par "salut, howzit, aloha" mais finissent par "s'il vous plaît respecter votre contrat de licence et arrêter l'ingénierie inverse de notre code, déjà."
Davidson explique qu'il y a un nombre croissant de clients soucieux de sécurité qui sont des logiciels Oracle de rétro-ingénierie à la recherche de failles de sécurité (ou l'embauche de consultants pour le faire pour eux). Davidson accuse ces clients de violer leurs accords de licence, de ne pas prendre de précautions de sécurité banales, d'essayer de faire le travail d'Oracle pour eux, et d'être généralement de mauvaises personnes. Si le client a trouvé une réelle vulnérabilité, alors Oracle va le réparer.
"Je déteste presque répondre à cette question parce que je tiens à réitérer que les clients ne devraient pas et ne doivent pas rétro-ingénierie de notre code. [...] nous ne donnerons pas à un client qui signale un tel problème (qu'ils ont trouvé par l'ingénierie inverse) un correctif spécial (ponctuel) pour le problème. Nous n'offrirons aucun crédit dans les avis que nous pourrions émettre. Vous ne pouvez pas vraiment nous attendre à dire «merci d'avoir rompu le contrat de licence».
Cela ne s'est pas très bien passé dans la communauté de la sécurité, et le message a été rapidement supprimé - mais pas avant de lancer un nouveau hashtag Hashtag Activism: #powerful ou #pointless? Activisme Hashtag: # puissant ou # sans point? #BringBackOurGirls, #ICantBreathe, et #BlackLivesMatter ont connu une large couverture internationale au cours de l'année écoulée - mais les hashtags sont-ils un moyen efficace de militer? Lire la suite .
"Vérifiez d'abord le CLUF d'Enigma", a déclaré Alan Turing. #oraclefanfic
- Thorsten Sick (@ThorstenSick) 11 août 2015
Mais, si vous n'êtes pas familier avec le monde de la sécurité, il peut ne pas être évident pourquoi le message original est si mal orienté. Donc, aujourd'hui, nous allons parler de la philosophie d'Oracle en matière de sécurité qui va à l'encontre du courant dominant, et de la raison pour laquelle c'est un problème.
Expliquer la controverse
Alors, qu'est-ce que le reverse engineering, et pourquoi Davidson s'en inquiète-t-il autant? Fondamentalement, lorsqu'Oracle publie un logiciel, il «compile» son code source interne dans des fichiers exécutables, puis livre ces fichiers aux clients. La compilation est un processus qui traduit le code lisible par l'homme (dans des langages tels que C ++) 3 Sites Web Pour commencer l'apprentissage Langage de programmation C ++ 3 Sites Web pour apprendre l'apprentissage C ++ Langage de programmation Apprendre à programmer peut être difficile pour beaucoup, même avec des langages de programmation relativement faciles Tandis que Java est plus facile à démarrer (où nous avons de nombreux articles ici à MakeUseOf pour Java ainsi que ... Lire la suite) dans un langage binaire plus dense qui peut être alimenté directement dans un processeur d'ordinateur.
Le code source d'Oracle n'est pas public. Ceci est destiné à rendre plus difficile pour les autres de voler leur propriété intellectuelle. Cependant, cela signifie également qu'il est très difficile pour les clients de vérifier que le code est sécurisé. C'est là que la «décompilation» entre en jeu. Fondamentalement, la dé-compilation se traduit dans l'autre sens, en convertissant les fichiers exécutables en code lisible par l'homme. Cela ne fournit pas exactement le code source d'origine, mais il fournit le code qui fonctionne de la même manière - bien qu'il soit souvent difficile à lire, en raison de la perte de commentaires et de la structure organisationnelle.
C'est le "reverse engineering" auquel Davidson fait référence. Oracle est contre parce qu'ils pensent que cela met leur propriété intellectuelle en danger. C'est au moins un peu idiot, parce que l'utilisation d'un accord de licence pour interdire le vol de la propriété intellectuelle est un peu comme l'utilisation d'un paillasson libellé sévèrement pour empêcher l'invasion de la maison. Les types de personnes qui tentent de cloner vos produits ne se soucient pas des accords de licence 4 façons de lire et de comprendre un contrat de licence d'utilisateur final (CLUF) Plus facilement 4 façons de lire et de comprendre un contrat de licence utilisateur final (CLUF) Plus facilement Les CLUF, ou Contrats de Licence Utilisateur Final, sont l'un des maux de la vie moderne. Ce sont des accords sans fin, généralement écrits en petits caractères. Ce sont les choses que vous faites défiler aveuglément, à la recherche de ce sacré ... Lire la suite, et souvent ne sont pas dans les juridictions où vous pouvez appliquer ces accords dans tous les cas.
L'humanité est condamnée ... #oraclefanfic #justoraclethings pic.twitter.com/e6MOZzkkvq
- CyberAnarchist (@ Cyb3rOps) 12 août 2015
La politique n'affecte vraiment que les clients légitimes. La situation est similaire à celle du jeu vidéo DRM 6 Places to Buy jeux sans DRM [MUO Gaming] 6 endroits pour acheter des jeux sans DRM [MUO Gaming] Depuis que j'ai décidé de ne pas acheter de jeux de Steam, j'ai besoin de trouver d'autres sources. Beaucoup d'entre eux sont en fait pire que Steam lui-même. Le magasin d'Ubisoft est déconcertant et plein de DRM agaçant. Electronic Art's ... Lire la suite, mais en quelque sorte encore plus inefficace.
Pourquoi les clients voudraient-ils décompiler ces exécutables? Tout est une question de sécurité. Avoir accès au code source vous permet de le parcourir à la recherche de bugs et de problèmes potentiels. Souvent, cela est fait en utilisant un logiciel qui effectue une «analyse de code statique» - une lecture automatique du code, qui identifie les bogues connus et les pratiques de logiciels dangereux qui ont tendance à conduire à des bogues. Bien qu'il existe des outils qui analysent directement le fichier exécutable, la décompiler permet des analyses généralement plus approfondies. Ce type d'analyse statique est un outil standard du commerce de la sécurité, et la plupart des entreprises soucieuses de la sécurité utilisent ces logiciels en interne pour produire du code qui est moins susceptible de contenir des bogues graves.
La politique d'Oracle sur ce type d'analyse est simplement «ne pas». Pourquoi? Je vais laisser Davidson m'expliquer.
"Un client ne peut pas analyser le code pour voir s'il y a un contrôle qui empêche l'attaque sur laquelle l'outil d'analyse crie (ce qui est probablement un faux positif) [...] Maintenant, je devrais noter que nous n'acceptons pas seulement Analyser les rapports comme «la preuve qu'il y a là, là», en partie parce que si vous parlez d'analyse statique ou dynamique, un rapport d'analyse n'est pas une preuve d'une vulnérabilité réelle. [...] Oh, et nous demandons aux clients / consultants de détruire les résultats d'une telle ingénierie inverse et de confirmer qu'ils l'ont fait. "
En d'autres termes, l'outil retournant un résultat n'est pas la preuve d'un vrai bogue - et puisque Oracle utilise ces outils en interne, il est inutile que les clients les utilisent eux-mêmes.
Le gros problème avec ceci est que ces outils d'analyse de code statique n'existent pas seulement pour attirer l'attention des bogues. Ils sont également censés servir de cible pour la qualité et la sécurité du code. Si vous jetez la base de code d'Oracle dans un outil d'analyse statique standard de l'industrie et qu'elle crache des centaines de pages de problèmes, c'est vraiment un mauvais signe.
La bonne réponse, lorsqu'un outil d'analyse de code statique renvoie un problème, n'est pas de regarder le problème et de dire 'oh, non, cela ne cause pas de bogue parce que tel ou tel'. La bonne réponse est d'entrer et de résoudre le problème. Les éléments signalés par les outils d'analyse de code statique sont généralement de mauvaises pratiques en général, et votre capacité à déterminer si un problème donné provoque réellement un bogue est faillible. Sur des milliers de problèmes, vous allez manquer des choses. Vous feriez mieux de ne pas avoir de telles choses dans votre base de code en premier lieu.
Voici OCCUS CTO John Carmack chantant les louanges de ces outils de son temps chez iD Software. (Sérieusement, lisez tout l'essai, c'est intéressant).
"Nous avons eu une période où l'un des projets a accidentellement désactivé l'option d'analyse statique pendant quelques mois, et quand j'ai remarqué et réactivé, il y avait des piles de nouvelles erreurs qui avaient été introduites dans l'intervalle. [...] Il s'agissait de démonstrations que les opérations de développement normales produisaient continuellement ces classes d'erreurs, et [l'analyse de code statique] nous protégeait efficacement contre beaucoup d'entre elles. "
En bref, il est probable que de nombreux clients d'Oracle n'essayaient pas nécessairement de signaler des bogues spécifiques - ils se demandaient pourquoi les pratiques de codage d'Oracle étaient si médiocres que leur base de code était truffée de milliers de problèmes si basiques qu'ils pouvaient être découverts par un logiciel automatisé.
Je suis toujours triste que Sun soit parti. Et qui était le génie qui les a vendus à Oracle? C'est comme laisser Dark Vador garder vos enfants.
- Brad Neuberg (@bradneuberg) 15 août 2015
Sécurité par des autocollants
Alors, que devraient faire les clients soucieux de la sécurité au lieu d'utiliser des outils d'analyse statique? Heureusement, le blog de Davidson était extrêmement détaillé sur ce sujet. En plus de préconiser des pratiques générales de sécurité de base, elle fait des suggestions concrètes à ceux qui s'inquiètent de la sécurité des logiciels qu'ils utilisent.
«Il y a beaucoup de choses qu'un client peut faire, gosh, parler aux fournisseurs de leurs programmes d'assurance ou vérifier les certifications pour les produits pour lesquels il y a des sceaux de bonne gestion (comme des sceaux de bon code) comme Critères Communs certifications ou certifications FIPS-140. La plupart des fournisseurs - du moins, la plupart de ceux que je connais - ont des programmes d'assurance assez robustes maintenant (nous le savons parce que nous comparons tous les notes lors de conférences).
C'est une réponse horrifiante d'une organisation aussi grande qu'Oracle. La sécurité informatique est un domaine en évolution rapide. De nouvelles vulnérabilités sont trouvées tout le temps, et formaliser les exigences de sécurité dans une certification qui est mise à jour toutes les quelques années est absurde. La sécurité n'est pas un autocollant. Si vous croyez qu'un logiciel crucial est sécurisé sur la base d'un sceau sur l'emballage, vous êtes irresponsablement stupide.
Heck, les outils d'analyse statique sont mis à jour beaucoup plus fréquemment que ces certifications - dans certains cas, tous les jours - et l'élimination de tous les problèmes qu'ils rencontrent n'est pas suffisante pour avoir confiance en la sécurité de votre code, car la plupart des vulnérabilités complexe à détecter par ces sortes d'outils automatisés.
La seule façon d'avoir confiance en votre propre sécurité est d'exposer votre code au monde entier, et demander aux pirates d'essayer de le casser. C'est ainsi que fonctionnent la plupart des grandes sociétés de logiciels: si vous trouvez un problème avec leur code, ils ne vous blâmeront pas de violer votre contrat d'utilisation. Ils vont vous payer de l'argent. Ils veulent que les gens fassent de leur mieux pour casser leur logiciel tout le temps. C'est la seule façon dont ils peuvent avoir confiance que leur code est sécurisé.
Ces programmes sont appelés programmes "bounty bug", et ils sont la meilleure chose à arriver à la sécurité au niveau de l'entreprise depuis longtemps. Ils sont également, par coïncidence, quelque chose que Davidson a des opinions assez fortes sur.
"Les bounties de bugs sont le nouveau groupe de boys (bien allitératif, non?) Beaucoup d'entreprises crient, s'évanouissent, et lancent des sous-vêtements aux chercheurs [...] de sécurité pour trouver des problèmes dans leur code et insistent sur le fait que vous ne faites pas de bogues, votre code n'est pas sécurisé.
Eh bien, nous trouvons 87% des failles de sécurité nous-mêmes, les chercheurs en sécurité en découvrent environ 3% et le reste est trouvé par les clients. [...] Je ne suis pas en train de disséquer les bogues, juste en notant que sur une base strictement économique, pourquoi devrais-je jeter beaucoup d'argent à 3% du problème. "
Pour commencer, basé sur les résultats de ces analyses de code statique, il pourrait s'avérer beaucoup plus que 3% si vous les avez payés. Mais je m'égare. Le vrai point est ceci: les primes de bogue ne sont pas pour vous, elles sont pour nous. Pourriez-vous trouver des bogues plus efficacement si vous avez dépensé le même argent pour des experts en sécurité interne? Bien, probablement pas - mais jetons un os d'Oracle et supposons qu'ils pourraient. Cependant, ils pourraient aussi prendre l'argent, le mettre en banque, et ensuite ne rien faire. Si la sécurité qui en résulte est inférieure à la normale, les clients ne s'en apercevront que des années plus tard, lorsque leurs numéros de sécurité sociale se retrouveront mystérieusement sur le web. Comment trouver des sites d'oignons actifs et pourquoi vous voudriez trouver des sites d'oignons actifs Pourquoi vous pourriez vouloir Les sites d'Onion, ainsi nommés parce qu'ils se terminent par ".onion", sont hébergés en tant que services cachés de Tor - un moyen complètement anonyme d'héberger des sites Web. Lire la suite .
"Il n'y a pas de vulnérabilité, le CLUF le dit". #oraclefanfic pic.twitter.com/cUfafDCWbv
- Schuyler St. Leger (@DocProfSky) 11 août 2015
Les bounties de bogue existent la moitié parce qu'elles sont une manière vraiment efficace d'identifier des bogues, et la moitié parce qu'elles sont une forme de sécurité que vous ne pouvez pas truquer. Une bogue de bogue indique de manière crédible au monde que tous les bogues laissés dans le code sont plus chers à trouver que la prime indiquée.
Les bounties de bogue n'existent pas pour votre commodité, Oracle, elles existent parce que nous ne vous faisons pas confiance.
Nous ne devrions pas non plus! Beaucoup de grandes entreprises permettent à la sécurité de tomber à l'eau, comme le confirme la cible jusqu'à 40 millions de clients américains. Les cartes de crédit potentiellement piratées confirment jusqu'à 40 millions de clients américains Les cartes de crédit potentiellement piratées Target vient de confirmer qu'un piratage aurait pu compromettre les informations de carte de crédit pour un maximum de 40 millions de clients qui ont magasiné dans ses magasins aux États-Unis entre le 27 novembre et le 15 décembre 2013. Lire la suite montre trop clairement. Vous êtes le deuxième plus grand fabricant de logiciels au monde. Il est absurde de nous demander de croire que vos produits sont sécurisés.
Ce que Davidson a raison
Pour être juste envers Davidson, il y a des éléments raisonnables dans leur contexte. Probablement, beaucoup de leurs clients entreprennent des audits ambitieux du code d'Oracle, sans prendre le temps d'éliminer les problèmes de sécurité plus banales de leurs systèmes.
Les «menaces persistantes avancées» - organisations de hackers expérimentés qui tentent d'avoir accès à des organisations spécifiques pour voler des données - sont effrayantes, mais en chiffres, elles sont beaucoup moins dangereuses que les millions de hackers amateurs opportunistes avec des outils automatisés. Faire ces sortes d'analyses statiques de logiciels commerciaux lorsque vous n'avez pas adopté les mesures de sécurité de base ressemble beaucoup à l'installation d'une salle de panique lorsque vous n'avez pas encore de verrou sur la porte d'entrée.
De même, il est probablement frustrant et inutile de se voir présenter la même analyse automatisée encore et encore et encore.
Cependant, pris dans son ensemble, l'article révèle des idées très obsolètes sur la sécurité du système, et la relation entre les développeurs et les clients. J'apprécie le fait que le travail de Davidson soit frustrant, mais les utilisateurs font tout leur possible pour vérifier la sécurité des logiciels qu'ils utilisent. Voici le président de Security Awareness, Ira Winkler:
"Oracle est une société très vaste et riche, avec des produits largement distribués et utilisés pour des applications critiques. Période. Ils ont la responsabilité de rendre leur logiciel aussi fort que possible [...] Il peut y avoir beaucoup de faux positifs et de coûts associés, mais c'est un facteur de [leur vente] beaucoup de logiciels qui ont beaucoup d'utilisateurs. C'est un coût de faire des affaires. Je suis sûr que toutes les sociétés de logiciels ont les mêmes faux positifs. Je n'entends pas Microsoft et al. se plaindre. "
Si Oracle ne veut pas continuer à recevoir des milliers de problèmes détectés par les outils de sécurité statique, ils devraient peut-être corriger ces milliers de problèmes. S'ils sont ennuyés par des gens qui retournent les mêmes non-bogues, peut-être qu'ils devraient avoir un bon programme de primes de bogue qui a des mécanismes pour traiter les soumissions répétées de non-problèmes. Les clients d'Oracle réclament un niveau de sécurité plus élevé, et les ignorer n'est pas la bonne réponse.
Bien qu'Oracle ait annulé et désavoué généralement le post, le fait qu'il ait été écrit révèle une culture de sécurité profondément erronée au sein d'Oracle. L'approche d'Oracle en matière de sécurité priorise la protection de sa propre propriété intellectuelle sur la sécurité et la tranquillité d'esprit de ses clients - et si vous confiez des informations critiques à un logiciel Oracle, cela devrait effrayer le bejeezus.
Qu'est-ce que tu penses? Êtes-vous préoccupé par la philosophie de sécurité d'Oracle? Pensez-vous que Davidson est traité trop sévèrement? Faites le nous savoir dans les commentaires!