Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

« 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

Le , par Stéphane le calme

23PARTAGES

8  2 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de derderder
Membre averti https://www.developpez.com
Le 13/08/2015 à 12:11
"Vous n'avez pas le droit d'appliquer le reverse-engineering dans notre code"
Si, on peut totalement, en tous cas en France :

Code de la propriété intellectuelle - Article L122-6-1

III. La personne ayant le droit d'utiliser le logiciel peut sans l'autorisation de l'auteur observer, étudier ou tester le fonctionnement ou la sécurité de ce logiciel afin de déterminer les idées et principes qui sont à la base de n'importe quel élément du logiciel lorsqu'elle effectue toute opération de chargement, d'affichage, d'exécution, de transmission ou de stockage du logiciel qu'elle est en droit d'effectuer.
7  0 
Avatar de BenNuts
Membre actif https://www.developpez.com
Le 13/08/2015 à 10:18
Citation Envoyé par sazearte Voir le message

Un peu comme si je découvrait une faille dans les cartes bancaire, et qu'on me mette en prison pour avoir alerter le gouvernement.
ça n'a pas réussi à Serge Humpich.
6  0 
Avatar de BugFactory
Membre expérimenté https://www.developpez.com
Le 13/08/2015 à 11:49
Citation Envoyé par Mary Ann Davidson
Ah, no. The point of our prohibition against reverse engineering is intellectual property protection, not “how can we cleverly preventcustomers from finding security vulnerabilities – bwahahahaha – so we never have to fix them – bwahahahaha.”
Avant d'accuser Oracle de négligence, il faut se rappeler qu'elle a des secrets industriels à protéger, il est donc parfaitement raisonnable qu'Oracle refuse l'ingénierie à rebours sur ses produits. Sinon n'importe qui pourrait, sous prétexte de recherche en sécurité, démonter le SGBD et s'en inspirer pour améliorer un produit concurrent.

Cependant cette approche a plusieurs problèmes :
- Ceux qui utilise l'ingénierie à rebours à fin d'espionnage industriel ne vont pas s'en vanter en faisant des rapports de bogues. Bien au contraire, plus il y a de failles dans Oracle, mieux c'est pour eux.
- Les clients qui font des rapports de bogues utilisent Oracle et sont peu susceptibles de développer eux-mêmes un produit concurrent.
- Les pirates qui recherchent des failles dans des buts illégaux ne vont pas se gêner pour décompiler le logiciel, quoique dise la license.
En d'autres termes, je ne suis pas convaincu par la sécurité par offuscation.

Je trouve aussi que le ton de ce post de blog est très irrespectueux. C'est à ses clients qu'elle s'adresse.
5  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 13/08/2015 à 12:50
Citation Envoyé par MichaelREMY Voir le message
je me doutais qu'il y aurait des réactions trolliennes voire machistes en lisant cette news.
Il n'y a plus beaucoup de développeurs qui respectent le travail des autres, pensant que tout est gratuit ou opensource ou à coffre-ouvert ou copiable donc sans valeur.
Et on pouvait tout autant se douter qu'il y aurait des gens qui réagiraient instinctivement au mot reverse-engineering sans prendre en compte le contexte.

Il ne s'agit pas en l’occurrence d'un problème de vol de propriété intellectuelle, mais de sécurité. Bien évidement que le reverse-engineering à des fins de copie est condamnable, mais de toute façon les personnes qui font ça ne vont pas contacter Oracle pour s'en vanter.

Là il s'agit de reverse-engineering à des fins d'analyse de sécurité. Si Oracle se met à menacer ceux qui remontent de vrais problèmes de sécurité au motif qu'ils y sont arrivés par reverse-engineering, il y a de quoi questionner leur politique de sécurité. Les pirates mal intentionnés se fichent pas mal du discours de Mary Ann Davidson, ils feront du reverse-engineering de toute façon et Oracle n'en saura jamais rien.
6  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 14/08/2015 à 1:06
Si, je l'ai noté aussi aussi et sur ce point je suis tout a fait d'accord : faire un rapport de vulnérabilité basé uniquement sur des outils d'analyse automatique est en effet une idiotie.
Mais ca n'excuse pas la réaction finale qui est tout simplement une menace d'action judiciaire envers toutes les personnes qui se questionnent sur la sécurité d'Oracle et pas seulement ceux qui font des rapports de vulnérabilité foireux.
5  0 
Avatar de earhater
Membre éclairé https://www.developpez.com
Le 13/08/2015 à 6:51
Aha si j'ai bien compris ce qu'elle veut dire c'est que si je (bon j'ai aucune chances hein) trouve une faille 0-day dans un logiciel oracle avec la solution de reverse engineering c'est que je risque plus un procès pour violation d'un contrat d'utilisation que de voir un correctif sortir ?
4  0 
Avatar de BufferBob
Expert éminent https://www.developpez.com
Le 13/08/2015 à 6:20
cette blague "vous n'avez pas le droit de reverser nos binaires" suivi d'un mouvement equissé de la main "les dataris feront l'affaire"

donc concrètement ça ne va pas empêcher les hackers de chercher des vulns dans les produits Oracle, la seule différence c'est que les vulns circuleront sous le manteau (0days) et/ou seront publiées anonymement au lieu de rentrer dans le processus classique qui fait qu'en général l'entreprise concernée sent qu'on lui met la pression et se dépêche de sortir un patch
3  0 
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
Le 14/08/2015 à 0:13
Je suis le seul a avoir compris de la news que ce qui l'emmerde c'est les gens qui décompilent pour ensuite faire une analyse statistique automatique aveugle et rapporter le même bug potentiel que 50.000 autres clients et qui n'en est pas un?
4  1 
Avatar de Bestel74
Membre confirmé https://www.developpez.com
Le 14/08/2015 à 20:24
Citation Envoyé par MichaelREMY Voir le message
je me doutais qu'il y aurait des réactions trolliennes voire machistes en lisant cette news.
Il n'y a plus beaucoup de développeurs qui respectent le travail des autres, pensant que tout est gratuit ou opensource ou à coffre-ouvert ou copiable donc sans valeur.

il y a une nuance entre "trouver une faille" et chercher une faille". Si vous ne comprenez pas cette nuance. Il n'est pas utile de répondre à ce sujet avec un point de vue professionnel éditeur ou programmeur.

J'avais déjà exprimé le même avis sur ce forum, et on m'avait lancer des pierres.

Je le répète, il i y a une nuance entre chercher et trouver.
C'est marrant mais tu savais que les licences privatives sont venus après ?
Le plus juste (historiquement) serait donc de penser :

"Il n'y a plus beaucoup d'entreprises qui développe dans esprit collaboratif afin d'améliorer leurs produit."
Et non pas l'inverse.

Refuser la collaboration sur un thème aussi critique que la sécurité d'un produit c'est juste se tirer une balle dans le pied et perdre en crédibilité.

Il n'y a qu'à voir : ce ticket, bien qu'émis par une personnalité importante, a été retiré. La te-hon quoi
3  0 
Avatar de derderder
Membre averti https://www.developpez.com
Le 18/08/2015 à 23:09
Citation Envoyé par acx01b Voir le message
les développeurs sont tous de droite mais râlent quand on leur rappelle ce que ça implique (codes sources protégés buggés et non performants écrits pas des stagiaires sous payés)

Fleur en plastique, le retour.
Ah tiens non.
3  0