« Vous n'avez pas le droit d'appliquer le reverse engineering sur notre code »

Le coup de gueule de la directrice de la sécurité d'Oracle

Mary Ann Davidson, la directrice de la sécurité d’Oracle, a rédigé un billet de blog qui a provoqué une polémique au sein de la communauté des chercheurs en informatique. « Non, vous ne pouvez vraiment pas », indiquait-elle en guise de titre d’un billet qui va s’avérer cinglant. « Récemment, j’ai observé une recrudescence dans le reverse engineering pratiqué par les clients dans notre code afin d’y chercher des vulnérabilités. < Insérez un grand soupir ici >. C’est la raison pour laquelle j’ai adressé de nombreux courriels à des clients débutant par ‘salut, comment ça va, aloha’ mais qui se terminaient par ‘s’il vous plaît, conformez-vous à votre contrat de licence et commencez déjà par arrêter de faire du reverse engineering à notre code’ », déclarait-elle.

Par la suite, Davidson a blâmé les entreprises tierces en expliquant qu’au lieu de se préoccuper des failles dans la sécurité des produits Oracle, elles devraient plus se focaliser sur leurs propres failles. « Ceci étant dit, vous pouvez être amenés à croire qu’avant de se préparer à courir des kilomètres supplémentaires, les clients se seraient déjà assuré d’identifier leurs systèmes critiques, de chiffrer leurs données sensibles, d’appliquer les correctifs adéquats, d’utiliser des produits supportés, d’utiliser des outils pour s’assurer que les configurations sont verrouillées – en bref, l’hygiène de sécurité habituelle – avant de tenter de trouver des vulnérabilités de type zero day dans les produits qu’ils utilisent ».

Pour elle, même si vous voulez obtenir une certitude raisonnable que les fournisseurs accordent une attention raisonnable à la façon dont ils conçoivent leurs produits, il y a une pléthore d’actions qu’un client peut effectuer comme parler au fournisseur de ses programmes d’assurance ou vérifier la certification des produits comme les certifications Common Criteria ou FIPS-140. « La plupart des vendeurs, du moins la plupart des gros bonnets que je connais, ont des programmes d’assurances robustes (nous le savons parce qu’il nous arrive de comparer nos notes durant des conférences) ». Elle estime que cela devrait suffire à arrêter le client diligent qui se dit « hé, je pense que je vais faire le travail du vendeur et rechercher les problèmes directement dans le code source moi-même » malgré le fait que :

• Un client n’est pas habilité à analyser le code pour vérifier s’il y aurait un contrôle qui empêche l’attaque de l’outil de scan
• Un client ne saurait produire un correctif, seul le vendeur peut le faire
• Un client se retrouve certainement à la limite de la violation du contrat de licence en se servant d’un outil qui fait de l’analyse statistique (qui opère dans le code source).

Mais qu’advient-il donc si quelqu’un trouvait une faille dans la sécurité d’un produit Oracle et le faisait remonter ? « Si nous déterminons dans le cadre de notre analyse que les résultats analysés pourraient UNIQUEMENT provenir d’un reverse engineering (au moins dans un cas, parce que le rapport avance, assez habilement, "analyse statistique d'Oracle XXXXXX", nous enverrions une lettre au client qui a pêché et une lettre différente au consultant qui a pêché et agit au nom du client, leur rappelant les termes de l'accord de licence Oracle qui prohibent le reverse engineering, donc, s'il vous plaît cessez déjà. (Dans le jargon juridique, bien sûr l'accord de licence Oracle a une disposition telle que : " le client ne saurait faire du reverse engineering, désassembler, décompiler ou alors tenter de dériver le code source des programmes ... " que nous citons dans notre missive au client) Ah, et nous demandons aux clients / consultants de détruire les résultats de ce reverse engineering et de confirmer qu'ils l’ont fait ».

Pourquoi en parle-t-elle ? Elle estime ne pas vouloir perdre de temps en disputes tournant autour de la question de la violation de licence, estimant que son équipe à mieux à faire, notamment travailler à l’amélioration du développement du code. « C’est le meilleur moment pour rappeler que je ne piétine personne simplement à cause de l’accord de licence. Comprenez plutôt “ je n’ai pas besoin de vous pour analyser le code puisque nous le faisons déjà, c’est notre devoir de le faire, et nous sommes assez bons dans ce que nous faisons. Nous pouvons, contrairement à une partie tierce ou un outil, analyser le code pour déterminer ce qui se passe. De plus, ces outils ont un taux de faux positif avoisinant les 100% alors, de grâce, ne perdez pas notre temps à rapporter la présence de petits hommes verts dans notre code “. Je ne suis pas en train de fuir nos responsabilités envers les clients, simplement, j’essaye d’éviter un exercice douloureux, gênant et qui entraîne une perte de temps mutuelle ».

Par la suite elle a répondu à une série de questions réponses pour affirmer encore plus son opinion. L’une d’elle par exemple évoque les Bug Bounty en disant « pourquoi ne pas créer un Bug Bounty ? Payer des tiers pour trouver des failles ». Ce à quoi elle répond « < plus gros soupir> les Bug Bounties sont le nouveau boy band (gentiment allitératif non ?). De nombreuses entreprises crient, s’évanouissent, et jette des sous-vêtements aux chercheurs en sécurité ***** pour qu’ils trouvent des problèmes dans leurs codes et insiste sur le fait que Ceci Est Le Chemin, Emprunte Le : si vous ne proposez pas de Bug Bounty, votre code n’est pas sécurisé. Pourtant, nous avons trouvé 87% des vulnérabilités de sécurité derechef, les chercheurs en sécurité n’ont trouvé que 3% et le reste par les clients (…) je ne dénigre pas les Bug Bounty, je remarque juste qu’en se référant strictement à l’économie, devrais je dépenser beaucoup d’argent pour 3% du problème quand je peux dépenser cet argent dans une meilleure prévention comme employer un autre collaborateur ».

Oracle a très vite retiré ce billet et a tenu à prendre ses distances. « Nous avons retiré ce billet parce qu’il ne reflète pas nos croyances ou notre relation avec nos clients. La sécurité de nos produits et services a toujours été important pour Oracle. Oracle a un programme robuste d’assurance sécurité produit et travaille conjointement avec des chercheurs en externe et des clients pour s’assurer que les applications conçues sur des technologies Oracle soient sécurisées », a expliqué Edward Screven, vice-président exécutif d'Oracle et architecte en chef de l'entreprise, dans un communiqué de presse.

Source : Scribd