Open source : les patchs de sécurité doivent-ils rester visibles ?

Par 05 septembre 2011 17 commentaires
open source

Rendre la gestion des correctifs de sécurité moins accessibles pourrait rendre leur détection moins aisée. Et donc décourager toute tentative de récupération frauduleuse.

Selon une équipe de chercheurs, Adam Barth, Saung Li,  Dawn Song et Benjamin I.P. Rubinstein,issus respectivement de l'université de Berkeley, de Google et de Microsoft, la visibilité des patchs de sécurité dans le code source augmenterait la fenêtre de vulnérabilité des projets en open source. Même si ces patchs sont camouflés au sein d'une multitude d'autres correctifs (ils constitueraient ainsi moins de 2 % des modifications totales), il reste possible pour une personne mal intentionnée d'exploiter les informations qui rapportent un bug ou qui évoquent la mise au point de ces correctifs de sécurité avant qu'ils soient appliqués.

Plus de vulnérabilité ?

Ainsi, si l'on en croit les scientifiques, l'utilisation d'un programme automatique chargé de balayer quotidiennement les dépôts de sources pourrait permettre d'augmenter la fenêtre de vulnérabilité de 6 à 10 fois. Du coup, pour y remédier, l'équipe propose une solution, qui peut prêter à polémique.

Dissimuler une partie des correctifs à l'ensemble de la communauté

Celle de rendre moins visible une partie des correctifs à la communauté, tout du moins jusqu'à ce que le problème soit réglé et que les informations soient envoyées aux utilisateurs. Leur postulat serait ainsi, éventuellement, de stocker ces données au sein d'un cercle de testeurs dédiés et moins important que l'ensemble des utilisateurs et membres, chargés de résoudre les problèmes avant de les rendre complètement publics.

Haut de page

17 Commentaires

"Par voie de fait, cette modification empêchera toute modification ultérieure, et donc toute optimisation du logiciel de ce point de vue-là. Mais il s'agit d'une perte mineure"

Oui, enfin, on pert tout de même la licence open source, hein, et on la viole au passage... d'un point de vu juridique c'est juste... illégal.

Soumis par Fabrice Epelboin (non vérifié) - le 05 septembre 2011 à 17h13

A oui, quelqu'un peut m'expliquer comment on peut séparer la partie sécurité ? Sa veux rien dire. Un programme peut présenter des faille dans d'autres endroit du code ou en soupçonnes même pas. Plus que ça, certains programmes à code fermer sont moins sécurisé que ceux à code ouvert BNP peut tu me rappeler quelle est l'Opering system sur le quel les virus aiment ce loguer ? Enfin, perso je pense que c'est dit chercheurs doivent revoir la parte programmation de leurs cours poste-recherche parce que là ils disent n'importe quoi ....

Soumis par zack (non vérifié) - le 06 septembre 2011 à 18h53

Les liens de Barth, Saung Li (Google), Dawn Song (chercheuse à Berkeley mais tout de même récipiendaire d'une bourse de IBM Faculty) et Benjamin I.P. Rubinstein (Microsoft) permet de douter largement sur l'objectivité de ladite étude. Et il suffit juste d'être logique pour comprendre que ce n'est pas la fameuse « partie sécurité » des codes Open Source qui constituent une faille, mais plutôt l'utilisation qu'en font les développeurs. C'est ridicule ou plutôt bien calculé : Google et Microsoft ont de très bonnes raisons d'effrayer les entreprises qui cherchent à renouveler leurs systèmes en brandissant le drapeau de la faille de sécurité chez la concurrence qui coûte évidemment moins chère puisqu'elle s'exonère des droits d'utilisation et de propriété d'un code... commercial.

Soumis par Olivier Gadeau (non vérifié) - le 05 septembre 2011 à 18h34

Hormis les problèmes de licence violée et des doutes quant aux objectifs réels de ces "chercheurs", le développement classique de l'Open Source -et qui a largement prouvé son efficacité est cassé :
- plus aucune possibilité de modification du code
- on ne peut plus évaluer la qualité du code

De la même façon, la plupart des technologie de sécurité (RSA, SSH etc.) sont largement meilleures que celles qui cachent leurs entrailles ...
Il faut choisir : exposer le code et le soumettre en vue de l'améliorer et prendre le risque qu'un pirate s'en saisisse ou le cacher, le figer et en rendre peut-être plus difficile le piratage mais aussi les réparations ...

Soumis par JL Pamart (non vérifié) - le 05 septembre 2011 à 21h16

Article étonnant ... mais les commentaires sonnent justes :)

On sait depuis longtemps que l'ouverture du code à pour conséquence ... une correction plus rapide des failles de sécurité !

Soumis par ocarbone (non vérifié) - le 05 septembre 2011 à 22h18

Heu, c'est pas les même gars qui pensent qu'une crypto est plus sûre quand son algo est secret ?
Les mega fails les plus récents (Sony, etc)reposent sur des codes en partie fermés
Sérieux, on est en 2011...

Soumis par providenz (non vérifié) - le 06 septembre 2011 à 15h02

Wow, incroyable, quelqu'un a vraiment écrit ça en 2011 ?

J'ai encore du mal à en croire mes yeux…
« A partir du code mis à disposition par les développeurs, il est possible d'identifier les failles du système, et donc de le pirater. Pour éviter cela, il est nécessaire de rendre inaccessible la partie "sécurité" du code. »
C'est évidemment la raison pour laquelle GNU/Linux et BSD sont bien connus pour être des passoires à côté de système fermés et plus robustes comme Windows ou OS X, c'est ça ?

Non, la sécurité par l'obscurité ne fonctionne pas. C'est la même chose en cryptographie, les algorithmes les plus sûrs sont ceux largement publiés et connus.

S'il est plus facile de trouver les failles grâce au code source, il est aussi plus facile de les corriger, et dans un projet open source, plus il y a de contributeurs, plus les failles sont trouvées vites et corrigées en conséquence.

Ouvert ou non, si la personne qui trouve une faille dans un logiciel veut s'en servir contre le logiciel, elle ne la rendra pas public. Mais avec un logiciel fermé, l'éditeur du logiciel aura tout intérêt à cacher ses failles.

Avec un logiciel libre, la transparence joue en faveur de l'utilisateur et de sa sécurité.

Soumis par thisisabore (non vérifié) - le 06 septembre 2011 à 15h05

J'ai l'impression qu'ils pensent que le net n'est truffé que de black hat en méprisant l'énorme communauté de white hat. La plupart des failles trouvées sont révélées... et corrigées en un temps record. Elles ne trainent pas des mois en attente de correction comme sur sur certaines plateformes propriétaires.

De plus, un système de sécurité qui s'écroule si son algorithme est révélé est un mauvais système de sécurité. Je ne me sentirai pas protégé par l'opacité d'un système si on me disait que c'est pour mon bien puisque si qqun savait comment ça marchait, tout s'écroulerait...

Nombre de systèmes ont une sécurité open source, voire libre et non seulement leur place de référence ET d'ouverture montre la qualité de l'algorithme de sécurité. Mais en plus les failles qui sont publiées (cf faille ssh qui a fait couler pas mal de gouttes de sueur) sont corrigées le temps d'un clin d'oeil.

Reste la question de la propagation des mises à jours qui peut avoir un coût pour une entreprise et c'est peut être ce coût qu'ils veulent éviter...

Soumis par Nem (non vérifié) - le 06 septembre 2011 à 15h09

Tomber encore sur des article comme ça c'est tout simplement pitoyable.
Du simple troll,
Ne perdez pas votre temps a commenter ce genre d'articles.

Soumis par toto (non vérifié) - le 06 septembre 2011 à 15h20

Version courte : oui on écarte les kiddies qui utiliseront des logiciels pour analyser le code (et d'autres pour exploiter les vulnérabilités éventuellement découvertes) mais un bon hacker est justement quelqu'un qui a une expérience réelle du code et de son fonctionnement et qui sera capable, en fonction du comportement d'une application d'en déduire le code qui la compose.

A l'inverse l'obscurité préconisée ici installera un sentiment de sécurité dans l'équipe chargée du développement alors que dans la pratique il n'en sera pas plus (si ce n'est moins) sécurisé.

L'exemple Linux / BSD vs Windows est très bon sur ce point et le rôle des communautés supportant les logiciels libres primordial dans la stratégie de sécurité. En gros : ayez une bonne communauté et les bugs seront remontés par elle et non par des hackers qui de toutes façons les rendront publiques, vous permettant de les corriger très vite...

Soumis par Paul (non vérifié) - le 06 septembre 2011 à 15h29

Mentions légales © L’Atelier BNP Paribas