Une faille dans le kernel Linux vieille de 9 ans corrigée, mais déjà exploitée

Une faille dans le kernel Linux vieille de 9 ans corrigée, mais déjà exploitée

Vieilles marmites

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

21/10/2016 3 minutes
163

Une faille dans le kernel Linux vieille de 9 ans corrigée, mais déjà exploitée

Une très sérieuse vulnérabilité dans le noyau Linux a été découverte. Déjà corrigée, elle est malheureusement déjà exploitée depuis un temps indéfini. La brèche est en effet présente dans le kernel depuis neuf ans, ouvrant au pirate des droits supérieurs à ce qu’il aurait en temps normal.

La vulnérabilité réside dans la manière dont Linux gère la mémoire, plus particulièrement dans une méthode de duplication nommée « copy on write ». En temps normal, de nombreuses zones de la mémoire ne peuvent qu’être lues. Mais si la faille est exploitée, l’attaquant peut obtenir des droits supérieurs et y écrire.

Une brèche vieille de neuf ans

Cette faille, estampillée CVE-2016-5195, existe depuis neuf ans dans le kernel Linux. Liée au fonctionnement de la mémoire, elle se retrouve dans pratiquement toutes les distributions existantes et peut donc être visée sur de très nombreuses machines, clientes ou serveurs. Par ailleurs, les méthodes d’exploitation sont non seulement simples à écrire, mais la vulnérabilité est déjà exploitée activement.

Comme indiqué par Ars Technica, c’est le développeur Phil Oester qui a découvert l’attaque. Il a d’ailleurs ouvert un site dédié pour en expliquer certains aspects. Selon lui, son code d’exploitation, compilé avec GCC 4.8.5, n’a pas besoin de plus de cinq secondes pour obtenir les droits root sur une machine. Or, si l’attaque vise un serveur, les conséquences peuvent être démultipliées.

Une attaque qui peut être couplée avec d'autres

L'obtention des droits root permet en effet de débloquer à peu près n'importe quel scénario. Dans le cas d’un serveur, il peut par exemple insérer du code malveillant dans les pages, pour tenter d’exploiter des failles sur la machine de l’internaute, avec installation de malware à la clé.

La faille, comme d’autres brèches sérieuses avant elle, a en tout cas déjà son sobriquet : « Dirty Cow », « cow » faisant ici référence à « copy on write ». Intervenant sur le sujet, Linus Torvalds se souvient avoir déjà tenté de corriger ce qui n'était alors qu'un bug il y a 11 ans. Il admet cependant qu’il s’y était mal pris et que la correction avait dû être abandonnée à cause de problèmes sur la plateforme s390.

La plupart des distributions déjà mises à jour

Toutes les distributions ne sont en l’état pas forcément vulnérables à l’attaque, même si la faille n’y est pas encore corrigée. Chez Red Hat par exemple, les versions 5, 6 et 7 de RHEL sont considérées comme atteintes, mais le code d’exploitation ne fonctionne pas sur les deux premières moutures.

Dans tous les cas, la brèche a été officiellement colmatée il y a trois jours et la grande majorité des distributions proposent déjà des correctifs à télécharger. Il est donc chaudement recommandé de vérifier la présence de mises à jour et d’installer celles qui seront disponibles.

163

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Une brèche vieille de neuf ans

Une attaque qui peut être couplée avec d'autres

La plupart des distributions déjà mises à jour

Commentaires (163)


Neuf ans, comme quoi, code visible ou pas, personne n’est à l’abri.











<img data-src=" />


Really ? une news sur un problème de sécurité un vendredi après 17 h ?



C’est même plus un happeau a troll la…



/me s’asseoit confortablement avec son sceau de popcorn !


J’entends les rageux de Cash Investigation se pointer, aïe aïe aïe


Y a t’il un petit code simple à compiler pour tester la vulnérabilité ?&nbsp;

Je vais faire les màj qui s’imposent, mais j’aime bien vérifier que les failles sont bien bouchés&nbsp;<img data-src=" />


Alors monsieur Torvalds Linus on fait quoi ?








bord a écrit :



Really ? une news sur un problème de sécurité un vendredi après 17 h ?



C’est même plus un happeau a troll la…



/me s’asseoit confortablement avec son sceau de popcorn !







Adresse Web :

https://postimg.org/image/ik9y7q9nz/



Sert toi si tu veux … <img data-src=" />









bord a écrit :



/me s’asseoit confortablement avec son sceau de popcorn !





Ça ne s’use pas un peu vite un sceau en pop-corn ? C’est un peu fragile il me semble.

Sinon, dans l’idée, ce n’est pas sot !









FRANCKYIV a écrit :



Adresse Web :

https://postimg.org/image/ik9y7q9nz/



Sert toi si tu veux … <img data-src=" />







C’est gentil en attendant ceux que pourra me servir Dâme Scarlett demain <img data-src=" />



( faut suivre les potins aussi ^^ )



Si c’était Windows, qu’est-ce qu’on entendrait comme bashing !



“Linus Torvalds se souvient avoir déjà tenté de corriger ce qui n’était alors qu’un bug il y a 11 ans. Il admet cependant qu’il s’y était mal pris et que la correction avait dû être abandonnée”



Et si c’était quelqu’un de chez Microsoft, il serait déjà figurativement crucifié.



Deux poids, deux mesures :)


et encore, imagine la réaction du lectorat si c’était une faille de cet âge lié à l’écosystème Apple.&nbsp;



Pire, imagine&nbsp;une faille de cet âge lié à l’écosystème Apple sur Clubic :peur:


C’est ça de faire confiance à des exégètes amateurs. N’empêche qu’il n’y a pas de porte dérobée dans Linux&nbsp;<img data-src=" /><img data-src=" />








millcaj a écrit :



Si c’était Windows, qu’est-ce qu’on entendrait comme bashing !





Bof, pas vraiment : des élévations de privileges de plusieurs années dans Windows on en patch plusieurs tous les mois https://technet.microsoft.com/en-us/library/security/ms16-oct.aspx - MS16-123, MS16-124 pour le mois d’octobre), et on n’en parle pas plus que ça. Sans doute parce que sous Linux c’est plus rare ?



&nbsp;<img data-src=" />









neves a écrit :



Bof, pas vraiment : des élévations de privileges de plusieurs années dans Windows on en patch plusieurs tous les mois https://technet.microsoft.com/en-us/library/security/ms16-oct.aspx - MS16-123, MS16-124, MS16-125 pour le mois d’octobre), et on n’en parle pas plus que ça. Sans doute parce que sous Linux c’est plus rare ?



&nbsp;<img data-src=" />







Bim



Les failles, y en a partout, il faut se résigner…

L’important, c’est de les corriger vite !



Je suppose que tous les OS ont eu leur propre vieille faille moche exploitée pendant des années…

Aucun logiciel n’est parfait, il faut se résigner. Ouais, c’est moche.


Sachant aussi que parfois un patch comble une faille mais en apporte une nouvelle, on doit patcher le patch … Bref l’erreur est humaine, les programmes sont faits par des humains, les patchs aussi, il faut donc supprimer l’humain on sera plus tranquille !



Plus y a de gruyère, plus y a de trous, plus y a de trous, moins y a de gruyère, Emmental mon cher Holmes.








jackjack2 a écrit :



Bim







Heu non, c’est parce que linux est plus rare. <img data-src=" />









after_burner a écrit :



Heu non, c’est parce que linux est plus rare. <img data-src=" />





Ou que tout le monde s’en fout&nbsp;<img data-src=" />



Les chats pourraient alors conquérir le monde !



Je ne sais pas si supprimer les humains est la solution du coup.


Les chats c’est rien que des branleurs qui passent leurs vies à jouer au babyfoot dans les bars et à fumer des pétards, on risque rien !








thomgamer a écrit :



Les chats c’est rien que des branleurs qui passent leurs vies à jouer au babyfoot dans les bars et à fumer des pétards, on risque rien !





C’était un communiqué du C C C le Comité Contre les Chats.



:grabpopcorn:








after_burner a écrit :



Neuf ans, comme quoi, code visible ou pas, personne n’est à l’abri.



<img data-src=" />









Ras le bol de ce système vérolé comme une vieille pute. Entre ça et les trous dans ssl vieux de 15 ans, il y en a vraiment marre de nous vendre ce système comme sécurité parce que libre. Ah putain…..










thomgamer a écrit :



Les chats c’est rien que des branleurs qui passent leurs vies à jouer au babyfoot dans les bars et à fumer des pétards, on risque rien !







va de retro chatanas <img data-src=" />



Bon, ben, une bonne raison de plus pour faire un sudo dnf upgrade chez moi…



J’ai même un kernel 4.8.2-300 en prime !


Ça correspond peut être à la mise à jour de kernel que j’ai eue tout à l’heure (opensuse).


Réponse de Linus Torvalds :&nbsp; C’est la faute de Nvidia ?



<img data-src=" />

‘dredi








tpeg5stan a écrit :



Réponse de Linus Torvalds :&nbsp; C’est la faute de Nvidia ?



<img data-src=" />

‘dredi





Ben en gros, il dit que c’est la faute d’IBM car son patch posait des problèmes sur mainframe… (dredi, tout ça…)









after_burner a écrit :



Heu non, c’est parce que linux est plus rare. <img data-src=" />







Aujourd’hui le noyau Linux est moins rare que Windows NT. Donc ça, ça marche pas non plus.









neves a écrit :



Bof, pas vraiment : des élévations de privileges de plusieurs années dans Windows on en patch plusieurs tous les mois https://technet.microsoft.com/en-us/library/security/ms16-oct.aspx - MS16-123, MS16-124 pour le mois d’octobre), et on n’en parle pas plus que ça. Sans doute parce que sous Linux c’est plus rare ?



&nbsp;<img data-src=" />





Le pire est que les changelogs d’update de sécurité de MS sont complètement abscons: on se sait pas quelle(s) version(s) de Windows sont impactés, quel composant du noyau NT est touché par faille, si c’est déjà exploité etc.









Haemy a écrit :



Ou que tout le monde s’en fout <img data-src=" />







Dit plus directement. <img data-src=" />



zefling a écrit :



Aujourd’hui le noyau Linux est moins rare que Windows NT. Donc ça, ça marche pas non plus.







Si on prend le cas d’androïd, il est justement plus sujet aux failles de sécurité car bien plus répandu qu’une distrib linux “classique”, en plus il est très mal maintenu.



Ça marche donc quand même. <img data-src=" />



<img data-src=" />&nbsp;Bien vu !



So Fuck You nVidia


Bien tenté , en plus on est vendredi, donc tu as le droit <img data-src=" />



Mais plus sérieusement, la lecture du code ne permet pas de déceler les failles, sinon il suffirait de les lister et faire un CTRL+F. Les failles se découvrent dans les cas d’usages non prévus…



Bon en l’occurrence elle n’est exploitable qu’en local, c’est un grand classique, c’est pas aussi grave que heartbleed.


Je ne comprendrais jamais comment il peut y avoir autant de failles dans un système informatique.



&nbsp;Si je suis bien, ces failles sont causées:

&nbsp;- soit par des erreurs dans l’écriture du code: dans ce cas, c’est juste par qu’on s’est retrouvé avec un codeur qui sait pas écrire (le genre de chose qui peut se corriger avec de la rigueur)




  • soit par une organisation des processus mal fichus ou pensés de façon incomplète: dans ce cas, le travail est à finir.

    &nbsp;

    Du coup, j’ai du mal à comprendre comment un système ne peut pas ne pas devenir infaillible.








millcaj a écrit :



Si c’était Windows, qu’est-ce qu’on entendrait comme bashing !



“Linus Torvalds se souvient avoir déjà tenté de corriger ce qui n’était alors qu’un bug il y a 11 ans. Il admet cependant qu’il s’y était mal pris et que la correction avait dû être abandonnée”



Et si c’était quelqu’un de chez Microsoft, il serait déjà figurativement crucifié.



Deux poids, deux mesures :)









Network a écrit :



et encore, imagine la réaction du lectorat si c’était une faille de cet âge lié à l’écosystème Apple.&nbsp;



Pire, imagine&nbsp;une faille de cet âge lié à l’écosystème Apple sur Clubic :peur:&nbsp;







Oui sans doute, mais les moyens de Microsoft et d’Apple sont-ils comparable à Linus Torvalds ?









bord a écrit :



/me s’asseoit confortablement avec son sceau de popcorn !





Petit joueur. La prochaine fois, viens avec une brouette. <img data-src=" />









sniperdc a écrit :



Alors monsieur Torvalds Linus on fait quoi ?





Ben, on met à jour. C’est écrit dans la niouze. <img data-src=" />









millcaj a écrit :



Et si c’était quelqu’un de chez Microsoft, il serait déjà figurativement crucifié.



Deux poids, deux mesures :)





Ha mais non. Torvald est un gros con prétentieux et despotique, on est d’accord.<img data-src=" />









Network a écrit :



et encore, imagine la réaction du lectorat si c’était une faille de cet âge lié à l’écosystème Apple.&nbsp;





Pour Apple, c’est différent. It’s not a bug, it’s a feature. <img data-src=" />









neves a écrit :



Bof, pas vraiment : des élévations de privileges de plusieurs années dans Windows on en patch plusieurs tous les mois https://technet.microsoft.com/en-us/library/security/ms16-oct.aspx - MS16-123, MS16-124 pour le mois d’octobre), et on n’en parle pas plus que ça. Sans doute parce que sous Linux c’est plus rare ?



&nbsp;<img data-src=" />





FUD. Le ministère de la défense fait confiance à MS. Moi je les crois. En plus, ils ont reçu toutes les garanties de la part de MS (en même temps que les valises de billets). Si ça c’est pas une preuve… <img data-src=" />









thomgamer a écrit :



Sachant aussi que parfois un patch comble une faille mais en apporte une nouvelle, on doit patcher le patch …





Tout le monde n’utilise pas Ubuntu. <img data-src=" />



oh la la comme il m’a cassé mon délire du vendredi&nbsp;<img data-src=" />


la population des utilisateurs est ultra importante dans ce genre de comparatif y’a un monde entre la population des windows clients et des windows serveur








Ricard a écrit :



Pour Apple, c’est différent. It’s not a bug, it’s a undocumented feature. <img data-src=" />





C’était pas le modjo de MS ça justement ? J’ai jamais réussi à retrouver l’origine de cette phrase.



&nbsp;



&nbsp;



Ricard a écrit :



Tout le monde n’utilise pas Ubuntu. <img data-src=" />





Ubuntu je sais pas, ma dernière Buntu remonte à 10.4, mais Android je sais qu’il y avait eu un patch de sécurité qui apporté une faille qui a donc du être repatché mais c’était plus tordu que ça, le patch faisait qu’en apparence android n’était plus touché par cette faille mais c’était que du pipeau <img data-src=" />



<img data-src=" />


De toute manière, dès qu’on veut faire quelque chose de sérieux, on utilise Windows. Linux est à la ramasse depuis des années !








Timothée a écrit :



De toute manière, dès qu’on veut faire quelque chose de sérieux, on utilise Windows. Linux est à la ramasse depuis des années !







<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



C’est sûrement le meilleur troll de tout ce vendredi !



aille… android est un kernel linux…



Donc le nsa a cette faille depuis 8 ans.

&nbsp;

Si ce n’est plus et comme la politique de mise à jour de android est déplorable à&nbsp; part sur certain modèles, ça pique grave….



&nbsp;


Ce n’est pas exploitable à distance. Il faut qu’une application infectée soit installée.

Mais c’est faisable.


Comme quoi ce n’est pas parce que le code est disponible que le logiciel est plus sûr : vu les compétences requises, à peu près personne ne va relire certaines portions.


Tu es développeur ? Si oui j’espère que c’est un troll

Sinon pour expliquer simplement :

Un système c’est millions de lignes d’instructions qui ont une logique défini mais par lequel il peut y avoir plusieurs scénarios possible.

Personne ne peut connaitre par cœur ces millions de lignes de code, comment elles interagissent entre elles et tous les scénarios possibles qui en découle.

Notamment sur un sujet aussi sensible, technique et pointu que le noyau Linux.

Bref, un système ne sera jamais infaillible, ça n’existe pas mais il est maintenu et tester pour toujours corriger au plus vite.

Et c’est pour ça que peut importe l’application que tu utilises, tu auras toujours des bugs. Sachant que pour une application on parle souvent d’une dizaine de milliers de ligne de code, le noyaux Linux c’est une dizaine de millions.


Je crois que ça vient d’une présentation de Windows. Bill Gates ayant, selon la légende, sorti cette phrase alors que l’OS faisait un BSOD.








js2082 a écrit :



Je ne comprendrais jamais comment il peut y avoir autant de failles dans un système informatique.



 Si je suis bien, ces failles sont causées:

 - soit par des erreurs dans l’écriture du code: dans ce cas, c’est juste par qu’on s’est retrouvé avec un codeur qui sait pas écrire (le genre de chose qui peut se corriger avec de la rigueur)




  • soit par une organisation des processus mal fichus ou pensés de façon incomplète: dans ce cas, le travail est à finir.

     

    Du coup, j’ai du mal à comprendre comment un système ne peut pas ne pas devenir infaillible.







    Malheureusement, le meilleur codeur du monde produit quand même des bugs.



    La perfection n’existe pas dans le travail humain.



Vous avez combien d’années de dev d’applis ERP/Distrib derrière vous ? Parce qu’écrire du code erroné, c’est beaucoup plus courant que ça : rien que les défauts d’analyse, les modifications en cours de projet, les budgets et les timings ultra serrés font des ravages. Oh, et puis ce sont des humains qui analysent, qui codent, qui testent et qui utilisent.

Donc le jour où je verrai un prog sans bogue, …non, en fait ça n’arrivera pas.


Son patch faisait sauter le level isolation ?








Aloyse57 a écrit :



Vous avez combien d’années de dev d’applis ERP/Distrib derrière vous ? Parce qu’écrire du code erroné, c’est beaucoup plus courant que ça : rien que les défauts d’analyse, les modifications en cours de projet, les budgets et les timings ultra serrés font des ravages. Oh, et puis ce sont des humains qui analysent, qui codent, qui testent et qui utilisent.

Donc le jour où je verrai un prog sans bogue, …non, en fait ça n’arrivera pas.





Tout le monde ne peut pas avoir les compétences de développeurs FreeBSD pour produire du code propre.



On peut avoir plus de détail sur cette faille ?



Quelles versions du kernel impacté ?

Quelles modules, options de compilation ?



Sur mon NAS en kernel 4.6.3-gentoo (gcc 5.4.0) le PoC se prend une segmentation fault…

Il n’aboutit pas non plus sur mon serveur en kernel 3.15.7-gentoo (gcc 4.7.3) !



ça ressemble encore à un FUD, avec une exploitation qui est bien moins facile qu’annoncée <img data-src=" />


Euh je suis pas certain, donc tout système tournant sous linux est potentiellement vérolé ?

D’autant que cela ne laisse pas de traces et on peut rien voir sur les logs.



Et Torvalds qui la ramène, oui mais moi je savais….


Du coup simple question mais android qui tourne sous linux est impacté ?

Et etant donné que pas mal de smartphone sont restés bloqués sur&nbsp;

android 4.4; 5.0; 5.1; 6; et sans aucune mises a jour, y’a pas un risque ?

Et du coup la faille est utilisable si on installe un fichier vérolé depuis l’app store non ?








js2082 a écrit :



Je ne comprendrais jamais comment il peut y avoir autant de failles dans un système informatique.



 Si je suis bien, ces failles sont causées:

 - soit par des erreurs dans l’écriture du code: dans ce cas, c’est juste par qu’on s’est retrouvé avec un codeur qui sait pas écrire (le genre de chose qui peut se corriger avec de la rigueur)




  • soit par une organisation des processus mal fichus ou pensés de façon incomplète: dans ce cas, le travail est à finir.

     

    Du coup, j’ai du mal à comprendre comment un système ne peut pas ne pas devenir infaillible.







    Tu as déjà développé des programmes ?



    Parfois ton code est parfaitement valide, mais après compilation tu as des bugs ou des failles qui apparaissent. Soit à cause d’une « optimisation » un peu trop agressive du compilateur (-O3 ?), soit à cause d’une autre option de compilation, soit à cause de bugs dans le compilateur (eh oui ça arrive aussi)…



    Certains bugs peuvent être effectivement dûs à des erreurs du programmeur. Parfois le programmeur est une tanche. Mais le programmeur peut être très bon, c’est quand même un humain qui peut se tromper, être fatigué, avoir dix projets sur le dos, un mauvais management… Et puis tout simplement, un OS n’est pas développé par un seul développeur hein ! Un OS contient des centaines de millions de lignes de code. Il faut des milliers de personnes pour mettre ça sur place (rien que pour le noyau Linux, il y a plus d’un millier de contributeurs). Quand un développeur reprend le code d’un autre pour le modifier, ou simplement appeler une fonction, il doit passer du temps à comprendre ce qu’a fait l’autre. Même si le développeur est bon, il peut être complexe de relire le code de quelqu’un d’autre.



    Si tu crois que développer un OS, c’est comme construire un mur où chaque dev pose sa brique, et que s’il y a un trou dans le mur c’est qu’un dev a mal fait son boulot, alors tu te trompes lourdement…



    Bref, les sources d’erreur sont multiples. Même avec des programmes courts, il y a de grandes chances que tu accumules facilement des bugs. Alors dans un OS… c’est tout à fait compréhensible qu’il reste des bugs et des failles, même après des années à les chercher et à les patcher.









v6relou a écrit :



Comme quoi ce n’est pas parce que le code est disponible que le logiciel est plus sûr : vu les compétences requises, à peu près personne ne va relire certaines portions.







Tu te bases juste sur la découverte d’un seul bug aujourd’hui pour dire ça ? Tu n’as pas l’impression de faire une généralisation complètement fausse ?



Il a déjà été démontré qu’un code comme celui de Linux contient moins de bugs par millier de lignes de code, que des logiciels propriétaires.



« Linux: fewer bugs than rivals », Wired (2004)



« Actually, Open Source code is better », PC World (2012)



« Linux is the benchmark of quality », PCWorld (2013)



Donc, si, le fait que le code source est disponible facilite la correction des bugs et des failles, et résulte donc en un code plus sûr. CQFD.



Bref renseigne-toi un minimum avant de faire des généralités dans le vent…



IBM et la gestion de la mémoire, c’est tout un poème… entre GPFS qui alloue massivement des physical pages&nbsp; (avec les effets secondaires que cela peut avoir), tous les produits allergiques à l’ASLR voir au no-execute, et tous les produits qui nécessitent de désactiver selinux parceque celui-ci bloque les librairies mal liées/chargées dans des zones mémoire improprement étiquetées ( problème qui, par ailleurs ne nécessiterait pas de désactiver selinux si les personnes chargées de maintenir les procédures d’installation chez IBM se documentaient un peu)


Open Source = Open Threat



<img data-src=" />








sniperdc a écrit :



oh la la comme il m’a cassé mon délire du vendredi&nbsp;<img data-src=" />





Désolé.<img data-src=" />



On t’a répondu déjà plusieurs fois mais je vais te donné un exemple concret pour que tu comprennes un peu mieux les difficultés : le cas de l’explosion du vol 501 d’Ariane 5, alias le feu d’artifice le plus chère du monde.



Ariane 5 utilise de bouts de programme développés pour Ariane 4. Jusque là, pas de problème, on ne réinvente pas la roue pour chaque nouveau modèle de charrette.

Parmi ces bout de programme, il y a une fonction utilisant une valeur d’accélération. Petit détail que personne n’avait repéré à ce moment là, c’est que cette valeur y est convertie en un entier non signé, c’est à dire uniquement un entier positif ou nul, codé sur 16bit. 16bit, ça permet de coder pour 65 536 valeurs (2^16). Pour entier dit non signé il est possible d’enregistrer une valeur entre 0 et 65 535.



Pour Ariane 4, cette taille d’entier était largement suffisant, il n’a pas été jugé nécessaire d’indiquer cette limitation. Cependant Ariane 5 avait une accélération bien plus importante au point de dépasser les capacité de cette variable. Comment ça a été géré par l’ordinateur, je ne sais pas, il faudrait regarder les spécification du langage, du compilateur et du processeur pour avoir les détail, mais ce qui est sûr, c’est que la valeurs en sortie de la fonction était alors totalement fausse.



L’ordinateur de la fusée ayant ainsi une valeur d’accélération ne correspondant pas à la réalité, il a cherché à rectifier. De la tout une suite d’événement a découlé vers la destruction de la fusée.








Konrad a écrit :



Il a déjà été démontré qu’un code comme celui de Linux contient moins de bugs par millier de lignes de code, que des logiciels propriétaires.



Donc, si, le fait que le code source est disponible facilite la correction des bugs et des failles, et résulte donc en un code plus sûr. CQFD.







Oui, le code est globalement plus sûr.

Non, ca ne prouve pas qu’il y ait moins de risques.



“Risk is the combination of End Effect Probability And Severity where probability and severity includes the effect on non-detectability (dormancy time). ”



Si l’open-source diminue le nombre total de bug dormants, il augmente aussi la facilité de trouver un bug. C’est le revers du mantra “tout le monde peut facilement trouver un bug et facilement le corriger”. Tout le onde peut accéder au code source…. et au bugtracker, aux historiques des commits, aux historiques des emails de discussions techniques.



Dans ce cas précis (et d’autres), l’existence du bug original, de son correctif et du retrait de ce correctif sont des informations qui ont été diffusées au public. Un public potentiel de 7 milliards d’humains.



Bref, on ne peut pas simplifier “moins de bugs = moins de risques”, pas plus qu’on peut simplifier “moins d’accès au source = moins de risques”. Les probabilités restent un ratio, et on ne peut pas agir seulement sur le numérateur ou seulement sur le dénominateur.



D’ailleurs, il y a toujours débat sur le “Full/Coordinated/Non Disclosure” des failles critiques. Comme quoi, “open” et “sécurité” ne sont pas forcément corrélés.




Comme quoi, JVachez était un visionnaire !








Commentaire_supprime a écrit :



Bon, ben, une bonne raison de plus pour faire un sudo dnf upgrade chez moi…



J’ai même un kernel 4.8.2-300 en prime !





Moi j’ai Linux 4.8.3









Timothée a écrit :



De toute manière, dès qu’on veut faire quelque chose de sérieux, on utilise Windows. Linux est à la ramasse depuis des années !





Ouh le vilain troll.



Moi aussi je vais apporter ma contribution, mais je vais être plus soft &nbsp;<img data-src=" />



Même le meilleur code au monde reste vulnérable.On écrit “des règles de jeu” avec un code, mais on trouvera toujours un gars plus malin qui exploitera ces règles à son avantage (un peu comme dans le Droit en fait), parce que le scénario dans lequel l’exploitation de la faille est réalisée n’était pas forcément évident à l’époque où le code était écrit.



Sans compter que comme déjà dit, le compilateur peut apporter son lot de surprise.


C’est triste mais fort juste. <img data-src=" />



C’est pour ça qu’un bon DSI doit garder en équilibre les possibilités d’appropriation du code et ses qualités intrinsèques. Un code auquel on ne peut pas toucher n’est pas spécialement plus intéressant qu’un code complètement modifiable, dont il s’avèrerait qu’il faut précisément tout refaire. XD



Sinon, sans déconner, ça craint là quand même. Une faille, ok.

Dans le noyau, à la rigueur (j’aurais plus compris s’il s’était agi de code récent vu comment le dev s’est accéléré depuis quelques temps, du moins en termes de nouvelles features).

Mais vieille de 9 ans.

Et connue par Torvalds de surcroît? oO



Bon, faut effectivement pas s’attendre à un vrai mea culpa vu la mentalité, mais ce serait amplement mérité pourtant…



&nbsp;








127.0.0.1 a écrit :



Comme quoi, “open” et “sécurité” ne sont pas forcément corrélés.







Bien entendu. Il ne suffit pas qu’un code soit Open Source, pour que magiquement il devienne invulnérable.



Cependant, je pense qu’on peut bel et bien parler d’une certaine corrélation : les logiciels libres sont moins souvent impactés par des exploits, et moins souvent infectés, que les logiciels propriétaires.



Si tu n’es pas convaincu par mon argument ci-dessus (nombre de bugs par ligne de code), considère le nombre d’infections de machines équipées de logiciels propriétaires VS logiciels libres. Sous Windows, au début des années 2000 le malware ILoveYou a infecté quelque 50 millions de machines, soit environ 10% des machines reliées à Internet à l’époque. Blaster a lui aussi infecté entre 8 et 16 millions de machines. Le ver Sasser, entre 500000 et 700000.



À côté de cela, les failles les plus graves et les plus médiatisées sous Linux (Heartbleed, Shellshock, Poodle, Stagefright…), ont été responsables de combien d’infections ? Parmi les attaques les plus importantes ces dernières années, on peut compter l’infection de 25000 serveurs sous UNIX et Linux, en 2014. Alors, ce genre d’infection est possible, oui Linux peut se faire attaquer, et ce sont des chiffres graves, une attaque de grande ampleur… mais qui reste tout de même moins importante comparée aux millions de PC infectés par Blaster, par exemple.



En 2015, 80% des infections concernent Windows, et seulement 20% Android, alors même qu’il y a davantage d’appareils Android en circulation que d’appareils Windows. Et sous Android, où se trouvent les failles exploitées ? Dans le noyau Linux ? Dans les logiciels GNU, dans les composants libres d’Android (AOSP) ? Non, la plupart des failles exploitées sont dans des API propriétaires de Google ou dans des applis propriétaires téléchargées depuis le Store, selon le rapport d’Alcatel-Lucent (page 5) : « Most Android malware is distributed as Trojanized apps that are downloaded and installed from Google Play and other third-party app stores. ».



Bref, la corrélation entre logiciels libres et sécurité me paraît assez claire. Après on peut toujours trouver des contre-exemples hein : des logiciels propriétaires particulièrement robustes, ou des logiciels libres complètement vérolés et faciles à attaquer. Mais quand on regarde les statistiques, globalement, les logiciels libres sont bien moins sources d’infections que leurs équivalents propriétaires.



Si tu lis le commentaire du commit corrigeant la faille, tu comprendras qu’il n’y aura pas de mea culpa. Linus semble plutôt minimiser l’importance du bug à l’époque de la correction initiale (what used a purely theoretical race back then has become easier to trigger).





Pour info, en ce qui concerne Debian, la faille est patchée dans security pour Wheezy et Jessie, et dans le dépôt standard pour Sid.



Upstream, le bug est corrigé dans toutes les LTS sauf la 3.4 (le patch de Linus ne fonctionne qu’à partir de la 3.9, qui implémente le dirty bit dans l’architecture s390).








Konrad a écrit :



Cependant, je pense qu’on peut bel et bien parler d’une certaine corrélation : les logiciels libres sont moins souvent impactés par des exploits, et moins souvent infectés, que les logiciels propriétaires.





Bien sûr, puisqu’il n’y a aucun intérêt à le faire. Les machines clientes sous Linux, c’est juste 1 ou 2% : aucun intérêt si tu cherches à toucher le maximum de monde.

Quant aux serveurs, c’est pas comparable : il y a beaucoup plus de précautions qui sont prises concernant la sécurité, et ce peu importe le système. Par exemple, le simple fait de ne pas installer d’applications ou de services inutiles réduit les vecteurs d’attaques possibles.



Et puis reste à voir ce qu’on appelle “infection”. Pour certains, la télémétrie à la Windows 10 est une infection.



Il faut aussi voir l’importance des faux-positifs, qui est un vrai fléau pour bon nombre de développeurs. Et j’ai bien l’impression, même si je n’ai rien pour le confirmer et que ça va en faire hurler certains, qu’au moins 90% des alertes d’antivirus sous Windows sont des faux-positifs.



Le truc que je développe sous Windows a beau être open-source, j’ai de plus en plus d’alertes sur VirusTotal. Plus je corrige de bugs, plus j’ai d’alertes. Je suis sur le point de publier une version avec 8 alertes sur 56…



Il te faut quoi pour que ça soie un mea culpa à tes yeux ??







Linus Torvalds a écrit :



This is an ancient bug that was actually attempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db9757a (“Fix get_user_pages() race for write access”) but that was then undone due to problems on s390 by commit f33ea7f404e5 (“fix get_user_pages bug”).




Tu ne peux pas comparer les taux sous Windows client et Windows serveur, le premier est utilisé par monsieur toutlemonde, le second par des professionnels.



Que linux soit moins impactés viens surtout du fait que c’est un os, utilisé essentiellement sur serveur, et pour les versions clientes la majorité des utilisateurs sont expérimentés.



Donc comparer des softs dont la typologie des utilisateurs n’a rien à voir, c’est un peu comme comparer une chausette et une voiture.



Pour ce qui est d’android tu fais fausse route aussi, tu compare un OS dont les applications via un store, et Windows dont les applications ne sont pas installés via un store. Il faudrait comparer Android et Windows phone, pas android et Windows en général c’est un non sens.


question bête de dev qui a un serveur debian pour faire mumuse.

Les derniers kernels supportés vont être corrigés, et donc un apt-get updateet apt-get upgrade suffiront pour maj son serveur?








teddyalbina a écrit :



Que linux soit moins impactés viens surtout du fait que c’est un os, utilisé essentiellement sur serveur, et pour les versions clientes la majorité des utilisateurs sont expérimentés.



[mode troll]

Linux n’a jamais été un OS et ne le sera jamais.

&nbsp;[/mode troll]



Résumer l’open-source à Linux et le propriétaire à Windows, c’est un peu restrictif.



L’IoT se développe a vitesse graaaaand V, et ce n’est pas windows et le monde propro qui est le leader la dedans mais plutot Linux et les technos open-source. Donc a va voir si notre monde va devenir plus “sécurisé”.



Comme le dit @teddyalbina, l’effort de recherche d’une faille dépend aussi de l’intérêt qu’on peut tirer de la découverte de cette faille. Il est plus lucratif de passer une journée à trouver une faille sur windows ou webkit, que trouver une faille sur reactos ou lynx.


En gros faut un accès physique à la machine c’est ça ?

Sinon moi aussi j’ai essayé de compiler le POC et ça fait juste un segfault sur un 3.6, un 3.8 , un 4.1 et 4.8 c’est normal ?

On en fait pas un peu trop avec ce truc ?








morpheus_ a écrit :



En gros faut un accès physique à la machine c’est ça ?







Non, pas besoin d’accès physique depuis qu’on peut exécuter un programme sur un ordinateur par intrication quantique depuis l’autre bout de la galaxie.







morpheus_ a écrit :



Sinon moi aussi j’ai essayé de compiler le POC et ça fait juste un segfault sur un 3.6, un 3.8 , un 4.1 et 4.8 c’est normal ?







oui, c’est normal d’avoir des segfault quand on commence à programmer en C sous linux. <img data-src=" />







morpheus_ a écrit :



On en fait pas un peu trop avec ce truc ?







C’est vrai que Linus Torvald à l’habitude de s’exprimer sur des futilités.









vampire7 a écrit :



Bien sûr, puisqu’il n’y a aucun intérêt à le faire. Les machines clientes sous Linux, c’est juste 1 ou 2% : aucun intérêt si tu cherches à toucher le maximum de monde.







Tu te trompes. Résumer Linux au desktop, c’est un peu restrictif. La majorité des terminaux clients Linux sont bien sûr les téléphones Android.



Il y aurait tout intérêt pour les pirates de chercher à exploiter des failles dans le noyau Linux, ou dans des logiciels libres utilisés dans Android (AOSP), car aujourd’hui ces terminaux sont plus nombreux que les PC Windows, et c’est là que les gens enregistrent leurs données personnelles : mots de passe, contacts, comptes bancaires… Donc oui, si tu veux toucher le maximum de monde, c’est tout à fait pertinent de viser les failles d’Android et de tous les logiciels libres sur lesquels il est basé.



Pourtant, les pirates préfèrent exploiter des failles dans les API propriétaires de Google, ou passer par des applis vérolées proposées dans le Store (le plus souvent, dans des stores alternatifs). Donc, sur cet exemple-là aussi on a un OS qui est basé sur de l’Open Source, mais ce sont essentiellement les composants propriétaires qui sont les cibles des attaques.









127.0.0.1 a écrit :



Résumer l’open-source à Linux et le propriétaire à Windows, c’est un peu restrictif.



L’IoT se développe a vitesse graaaaand V, et ce n’est pas windows et le monde propro qui est le leader la dedans mais plutot Linux et les technos open-source. Donc a va voir si notre monde va devenir plus “sécurisé”.



Comme le dit @teddyalbina, l’effort de recherche d’une faille dépend aussi de l’intérêt qu’on peut tirer de la découverte de cette faille. Il est plus lucratif de passer une journée à trouver une faille sur windows ou webkit, que trouver une faille sur reactos ou lynx.







Quand on parle d’OS, comparer le propriétaire et le libre revient bien à comparer Windows et Linux. Après, dans les documents que j’ai cités les statistiques sont faits sur davantage de logiciels, et pas seulement sur les OS. Tu peux aller les consulter.



Et sinon, j’aimerais bien que vous me donniez des sources aussi, et des données objectives, plutôt que des suppositions à base de « on va voir », « peut-être que ».









teddyalbina a écrit :



Tu ne peux pas comparer les taux sous Windows client et Windows serveur, le premier est utilisé par monsieur toutlemonde, le second par des professionnels.



Que linux soit moins impactés viens surtout du fait que c’est un os, utilisé essentiellement sur serveur, et pour les versions clientes la majorité des utilisateurs sont expérimentés.



Donc comparer des softs dont la typologie des utilisateurs n’a rien à voir, c’est un peu comme comparer une chausette et une voiture.



Pour ce qui est d’android tu fais fausse route aussi, tu compare un OS dont les applications via un store, et Windows dont les applications ne sont pas installés via un store. Il faudrait comparer Android et Windows phone, pas android et Windows en général c’est un non sens.







Les serveurs sont effectivement à part.



En revanche, je pense que la façon d’installer des logiciels ne change pas grand chose. Alors oui, sous Windows les gens vont télécharger n’importe quoi sur le Web. Mais sous Android, les gens ajoutent des Stores alternatifs, et c’est là qu’ils chopent des malwares…



Par ailleurs, quand Sasser et Blaster étaient en circulation, les gens ne se faisaient pas infecter en installant n’importe quoi. Il suffisait d’être connecté au Net pour se faire infecter. Les malwares exploitent des failles de l’OS (ou de logiciels installés), la façon dont tu installes tes applis tierces ne change pas grand chose…









127.0.0.1 a écrit :



Non, pas besoin d’accès physique depuis qu’on peut exécuter un programme sur un ordinateur par intrication quantique depuis l’autre bout de la galaxie.

&nbsp;







oui, c’est normal d’avoir des segfault quand on commence à programmer en C sous linux. <img data-src=" />







C’est vrai que Linus Torvald à l’habitude de s’exprimer sur des futilités.




Il suffit d’aller faire sa promenade du dimanche sur shodan pour voir que c’est pas vraiment top niveau sécurité certains iot actuellement dont des trucs bien plus critique qu’une netcam alacon… <img data-src=" />








127.0.0.1 a écrit :



Non, pas besoin d’accès physique depuis qu’on peut exécuter un programme sur un ordinateur par intrication quantique depuis l’autre bout de la galaxie.





Mon pc contient trop de quantité de matière pour se comporter en objet quantique et interagir par intrication.

&nbsp;





127.0.0.1 a écrit :



oui, c’est normal d’avoir des segfault quand on commence à programmer en C sous linux. <img data-src=" />



Moi j’aime bien les Segfault. Sous MsDos3 j’avais pas le droit au message, j’avais juste l’opportunité d’appuyer sur le bouton reset de la machine (l’arithmétique foireuse des pointeurs sur des void * sous MS Dos pour adresser la carte vidéo ça pardonne pas).

&nbsp;



127.0.0.1 a écrit :

C’est vrai que Linus Torvald à l’habitude de s’exprimer sur des futilités.



Tu le connais bien dis donc, t’en communication par intrication quantique avec lui ?



Merci pour ton excellent sens de l’humour, ta réponse était passionnante.

Sinon quelqu’un a réussi à compiler ce POC ?



Sinon je comprends pas, le code est pourtant limpide (j’adore le C :) )

#include &lt;stdio.h&gt;

#define _\(() 0

#define \_\_\)
() 1

#define _\(\_() 10

#define \)
_\((a) a;

#define \)
_(b,a) a##b

#define r(a,b) r##a##b##urn 0;

#define m(b,a,x) }; m##a##b##n

#define \((b,a,x) a##b##x

#define \_\_\_\_ + \_\_

#define \)
_\(\_ =

#define \_\_(...) ( \)
(n,i,t))(\

\((ze,si,of)((\)(n,i,t)[]) { _\((), ##\_\_VA\_ARGS\_\_})/\)(ze,si,of) (\((n,i,t))-\_\_\)())

\((n,i,t) (*\_\_\_) (\)(n,i,t)) = \((tch, pu, ar); \)(ub,do,le) _&lt;::&gt; \(\_\)_ &lt;%




       -2, 1, -1.3, 1.3     /* &lt;-- Configure here: X1, X2, Y1, Y2 */    





,_\((), \_\)(),_\((),\_\)(),_\(() ,\_\)(), __( ‘,’,‘,’,‘,’ ,‘,’ ,‘,’) * _\(\_() ,( \_\)_()




  • __(’_’,’_’)) _\(\_(), \_\)(),_\((),\_\)(),__(’_’,’_’)__(’_’,’_’, ‘_’,’_’, ‘_’) *

    __(’_’,’_’, ‘_’,’_’, ‘_’)*__(’_’,’_’, ‘_’,’_’, ‘_’)+__(’_’,’_’, ‘_’,’_’ , ‘_’)

    ,__(’_’,’_’,’_’,’_’,’_’,’_’,’_’,’_’,), _\(() m(i,a,u)(\)(n,i,t) \(\_)&lt;% \)_ (f,i) (

    \(\_ \)_(=,=) __(_) ) \(\_\)(\(\_(f,i)(\_[ \_\)_()____(_,_) ]&gt;_[ _\(\_()] )\_[\_\)_()____ (_,_

    ,_,_,_,_,_)] \(\_\)_ __(_) )\(\_(f,i)(\_[\_\)_()____(_ ,_ ,_)] &gt;_[ _\(\_()+ \_\_\)() ] ||

    _[_\(\_()\_\_\_\_(\_,\_,\_,\_,\_,\_,\_)] \)_ (=,=) __\(()) r(e,t) \_[\_\_(\_,\_,\_ ,\_,\_ ,\_)] \)_\(\_ \_

    [\_\_ (\_,\_,\_,\_,\_,\_,\_)\_\_\_\_(\_,\_,\_,\_,\_,\_) ]/\_[\_\_(\_,\_,\_,\_,\_) \_\_\_\_(\_,\_,\_,\_,\_,\_)]*( \_[

    \_\_\)
    ()]-_[_\(()])+\_[ \_\)() ];_[__(_,_,_,_,_,_,_)] \(\_\)_ _[__(_,_,_,_,_,_,_) ____

    (_,_,_,_,_)]/_[_\(\_()]*(\_[\_\_(\_,\_,\_,)]-\_[\_\_(\_,\_,)] )+\_[\_\_(\_,\_,)];\_[\_\_(\_,\_,\_,\_, \_

    ,\_,\_,\_)] \)
    _\(\_ \_[\_\)_() - __\(()] \)_\(\_ \_[\_\_(\_,\_,\_,\_,\_)+ \_\)_()-__\(()] \)_\(\_ \_\)();

    _f:_[__(_,_,_,_)] \(\_\)_ _[__( _,_,_,_, _,_,_, _)] * _ [__(_,_,_, _,_,_,_,_)];

    _[__(_,_,_,_,_)] \(\_\)_ _[_\(\_() - \_\_\)()]*_[_\(\_() - \_\_\)()];_[__(_,_,_,_,_,_,_,_,_

    )] \(\_\)_ __(_,_)_[__(_,_,_,_,_,_,_,_)]_[_\(\_() -\_\_\)()]+ _[__ (_,_,_,_,_,_,_)];

    _[__(_,_,_,_,_,_,_,_)] \(\_\)_ _ [ __(_,_,_,_) ]-_[__(_,_,_,_,_)]+_[__(_,_,_,_,_,

    _)];\(\_\)(_[_\(\_()\_\_\_\_(\_,\_,\_,\_,)]++)\)_(f,i)((_ [_\(\_() \_\_\_\_ (\_,\_,\_,\_,)]&lt; \_ [\_\)_ ()

    ____ (_,_,_,_,_)])&&(_[__(_,_,_,_)]+ _[__(_,_,_,_,_)]&lt;_[_\(\_()\_\_\_\_(\_,\_,\_,\_,\_,\_)

    ])) \)
    _(to,go) _f; \(\_(ar,ch) \)(m,i,au)[] \(\_\)_ &lt;% __(_,_,_) * _\(\_()\_\_\_\_(\_,\_), \_\_

    (\_,\_,\_,\_) * \_\)
    _()____(_,_,_),__(_,_,_,_,_,_) * _\(\_()\_\_\_\_(\_,\_,\_,\_), \_\_(\_,\_,\_,\_)

    *\_\)
    _() ____(_,_,_,_,_),__(_,_,_,_) _\(\_() \_\_\_\_(\_,\_,\_,\_,\_,\_),\_\_(\_,\_,\_,\_) \ \_\)_

    ()____(_,_) %&gt;;___(\((m,i,au)[(\)(n,i,t)) _[_\(\_()\_\_\_\_(\_,\_,\_,\_)]%\_\_(\_,\_,\_,\_,\_)]);

    \)
    _\((\_[\_\_(\_,\_ ,\_,\_ ,\_,\_,\_) + \_\_(\_,\_,\_,\_,\_,\_)]++){m(i,a,u) ( \_\)()) ;\(\_\) (_[_\(\_()

    \_\_\_\_(\_,\_)]++)\)
    _\((\_[\_\)_()____(_,_,_)] \(\_\)_ _\(()) \)_(f,i)(_ [__(_,_,_,_,_,_,_) +

    _\(\_()] != \_\_(\_)) \_\_\_(\_\)_()) ;{ m(i,a,u)(__$()); r(e,t) / IOCCC 2014/ %&gt;



    PS: ce code compile sans segfault :)


Je n’interprète pas ça comme un mea culpa, plutôt comme une exposition factuelle et concise de la situation, mais en même temps je n’attend pas particulièrement d’excuses ou de remise en question. On me propose depuis 25 ans un noyau libre, gratuit, maintenu et en amélioration permanente, je ne vais pas me plaindre.








étienne a écrit :



question bête de dev qui a un serveur debian pour faire mumuse.

Les derniers kernels supportés vont être corrigés, et donc un apt-get updateet apt-get upgrade suffiront pour maj son serveur?





Sous Debian Wheezy c’est corrigé depuis la 3.2.82-1 (disponible le 20)

Sous Debian Jessie c’est corrigé depuis la 3.16.36-1+deb8u2 sous Jessie (mise à jour le 19)



Si tu as fait la mise à jour et redémarré le serveur, comme il faut le faire en cas de mise à jour noyau, allors c’est bon. Tu peut vérifier avec la commande “uname -a”.



Comme dit plus haut, toutes les versions du noyau encore supportées sont déjà corrigées, sauf une (3.4).



Pour Debian, si tu utilise une version non obsolète, la mise à jour du système installe un noyau corrigé si tes dépôts sont correctement configurés (debhttp://security.debian.org/… pour Wheezy et Jessie).


&gt;toutes les versions du noyau encore supportées sont déjà corrigées,



Après 9 ans … “déjà” corrigées … <img data-src=" />


???

&nbsp;On peut pas corriger une faille qui n’est pas encore découverte ! Par contre la corriger dans toutes les distributions quelques heures après la découverte, c’est assez impressionnant.

Sinon quelqu’un a réussi à exécuter un exploit de cette faille ? Chez moi ça compile mais ça segfault sur tous les noyaux que j’ai testés. Ca serait pas encore un gros FUD ce machin ?








morpheus_ a écrit :



Merci pour ton excellent sens de l’humour, ta réponse était passionnante.







Ah parce que c’était sérieux quand tu demandais “En gros faut un accès physique à la machine c’est ça ?”.



Tu croyais que le programme s’exécuterai mieux si tu pouvais physiquement toucher le boitier du PC ?



Et bien… non. Il n’y a pas besoin d’un “accès physique à la machine” pour exécuter un programme.



La fameuse intrication quantique et les marmottes, le papier alu tout ça…

Bonne soirée.








morpheus_ a écrit :



Sinon quelqu’un a réussi à exécuter un exploit de cette faille ? Chez moi ça compile mais ça segfault sur tous les noyaux que j’ai testés. Ca serait pas encore un gros FUD ce machin ?



Oui, compilé et testé avec succès la variante utilisant PTRACE_POKETEXT sur un noyau Gentoo hardened et une tablette Android Samsung en 4.4.2.



Dommage d’ailleurs, j’ai pas trouvé de binaire avec le setuid flag sinon j’aurais enfin eu une méthode simple et sûr de rooter ma tablette sans toucher au recovery, va falloir creuser un peu plus pour trouver une méthode plus vicelarde, mais cela ne m’a jamais semblé être autant envisageable que maintenant… <img data-src=" />









fred42 a écrit :



Ça ne s’use pas un peu vite un sceau en pop-corn ? C’est un peu fragile il me semble.

Sinon, dans l’idée, ce n’est pas sot !





Moi aussi j’ai bloqué dessus. Mais ce con de Google trouve quand même des photos de “sceau de peinture” !



Pour les fainéants =&gt; seau !



<img data-src=" />







sniperdc a écrit :



Alors monsieur Torvalds Linus on fait quoi ?





un doigt d’honneur &nbsp;<img data-src=" />



&gt; Et bien… non. Il n’y a pas besoin d’un “accès physique à la machine” pour exécuter un programme.



il se lance par la gloire du saint esprit ? tu es capable d’ouvrir des connexions ssh par la pensée toi ?


Je me demande si la faille est exploitable avec SELinux ? Vous savez, ce truc que tout le monde désactive <img data-src=" />








Obidoub a écrit :



Je me demande si la faille est exploitable avec SELinux ? Vous savez, ce truc que tout le monde désactive <img data-src=" />





Teste ici sur CentOS6.8 et CentOS7.2 avec SELinux actif et l’exploit ne fonctionne pas.

Heureusement sinon j’aurai du passer le weekend a patcher mes 2000+ servers Linux…



Il peut y avoir une faille sur le serveur permettant d’exécuter un fichier préalablement uploadé.








doom_Oo7 a écrit :



il se lance par la gloire du saint esprit ? tu es capable d’ouvrir des connexions ssh par la pensée toi ?



Bah déjà, pour te connecter en SSH à une machine, par définition, t’as pas besoin d’y avoir un accès physique. Ensuite, il n’y a pas que via SSH que l’on peut effectuer des appels systèmes.



En gros, au moins tous les hébergeurs mutualisés sont potentiellement impactés. Et tu associes ça à une éventuelle faille sur un service, c’est n’importe quelle machine accessible en ligne qui devient une cible potentielle en puissance.







Obidoub a écrit :



Je me demande si la faille est exploitable avec SELinux ? Vous savez, ce truc que tout le monde désactive <img data-src=" />



Ça dépends des protections. En l’état actuel des choses, il faut bloquer à la fois l’écriture dans /proc/self/mem, et l’utilisation de ptrace. Autant la première, c’est surement le cas dans la majorité des configurations, autant la deuxième option, je ne suis pas sûr qu’elle soit aussi répandue.







fmo a écrit :



Teste ici sur CentOS6.8 et CentOS7.2 avec SELinux actif et l’exploit ne fonctionne pas.

Heureusement sinon j’aurai du passer le weekend a patcher mes 2000+ servers Linux…



Tu as testé un PoC à base de PTRACE_POKETEXT ? J’espère que oui, sinon bonne fin de week-end… <img data-src=" />









js2082 a écrit :



Je ne comprendrais jamais comment il peut y avoir autant de failles dans un système informatique.



&nbsp;Si je suis bien, ces failles sont causées:

&nbsp;- soit par des erreurs dans l’écriture du code: dans ce cas, c’est juste par qu’on s’est retrouvé avec un codeur qui sait pas écrire (le genre de chose qui peut se corriger avec de la rigueur)




  • soit par une organisation des processus mal fichus ou pensés de façon incomplète: dans ce cas, le travail est à finir.

    &nbsp;

    Du coup, j’ai du mal à comprendre comment un système ne peut pas ne pas devenir infaillible.





    Personne n’est infaillible et en général les bugs/failles sont apportées par de nouvelles fonctionnalités. Or, la communauté d’utilisateurs est friande et demandeuse de ces nouvelles fonctionnalités. Les développeurs étant humains (donc pas parfaits), de telles erreurs surviennent. Après il est possible de mettre le paquet sur les tests mais cela coute cher et prend du temps. J’ai suivi une formation de Qualification Logicielle en 2013 (45 Jours) et la première chose que l’on nous apprend c’est que les tests ne peuvent pas être exhaustifs et que dans un projet, la qualification est souvent négligée (pour les raisons que j’ai évoquées ci-dessus)…



&gt; il se lance par la gloire du saint esprit ? tu es capable d’ouvrir des connexions ssh par la pensée toi ?



et t’es davantage capable d’ouvrir une connexion ssh quand tu peux toucher le boitier ?


les commentaires de 2show7, Patch, Inextenza, Konrad, Miles Prower et Soriatane (cf libristes intégristes) sont invités à s’expliquer sur l’argumentation infondée de leurs propos déversés dans les commentaires de l’article de cash investigation ici meme, on détient maintenant un argument béton que non, opensource/libre est et restera un gage d’adaptation vanté par Stallman, non un gage de sécurité : qui a le temps d’analyser l’entièreté du code source disponible sur la planete internet?









Konrad a écrit :



Les serveurs sont effectivement à part.



En revanche, je pense que la façon d’installer des logiciels ne change pas grand chose. Alors oui, sous Windows les gens vont télécharger n’importe quoi sur le Web. Mais sous Android, les gens ajoutent des Stores alternatifs, et c’est là qu’ils chopent des malwares…



Par ailleurs, quand Sasser et Blaster étaient en circulation, les gens ne se faisaient pas infecter en installant n’importe quoi. Il suffisait d’être connecté au Net pour se faire infecter. Les malwares exploitent des failles de l’OS (ou de logiciels installés), la façon dont tu installes tes applis tierces ne change pas grand chose…







C’est pas parce que les failles ne sont pas encore exploitées à grande échelle que le danger est moindre.



D’ailleurs ils faudrait savoir comment sont comptabilisés les infections dans le cas d’abdroïd et de windows, une appli de type malware récupéré sur un store aura peut être tendance à passer plus inaperçue qu’un malware sur le net, voir à ne pas être considérée comme une application malveillante vue les différences d’usages entre un smartphone et un PC.



Et bien évidement tous les appareils connectés, tablettes smartphones fonctionnant sous Android ne seront jamais corrigés…. merci Google pour cette daube qui n’a aucun système de diffusion indépendant du fabricant !

La récente attaque est un exemple édifiant du pire qui nous attend et Google avec Android en sera l’acteur principal.

Les autorités de régulation devraient anticiper et obliger éditeurs et fabricants à corriger leurs vulnérabilités….








AlphaBeta a écrit :



Et bien évidement tous les appareils connectés, tablettes smartphones fonctionnant sous Android ne seront jamais corrigés…. merci Google pour cette daube qui n’a aucun système de diffusion indépendant du fabricant !

La récente attaque est un exemple édifiant du pire qui nous attend et Google avec Android en sera l’acteur principal.

Les autorités de régulation devraient anticiper et obliger éditeurs et fabricants à corriger leurs vulnérabilités….







le probleme n’est pas google

google est le premier a rendre disponible les mises à jour de son os android

le probleme est le nombre d’appareils à prendre en charge, est à la charge complete du fabricant (comme mac/iphone, pour apple) contrairement à un modele comme windows ou tout est à charge de microsoft pour simplifier.



ainsi, en connaissance de cause, je sais que mon zte blade s, déjà obsolete mais toujours sur les rails, que ma tablette lenovo, dans cinq ans, ne toucheront évidemment plus les mises à jour :

tant pis, j’ai compris que libre ou non libre l’enjeu reste le meme :

black hat, marché noir ou NSA (oui ca rime), tous peuvent avoir un droit de séjour illicite dans mon appareil, donc je ne met rien de sensible dedans. Le matelas est plus sécurisé la dessus.



ou est ce que je veux en venir?

depuis cette mode de l’ultra-connecté par le haut débit fixe et mobile, les utilisateurs n’ont pas pris conscience à réfléchir à la confiance à accorder à ces appareils, ils préfèrent taper sur un responsable (éditeur, développeur..) plutot que de s’abstenir, de se modérer afin d’éviter les conséquences d’une fuite de données personnelles.




Merci pour les éclairages d’un peu tout le monde (non, je ne suis pas codeur, ni même un troll).



Je pensais que les étapes de création de code étaient strictement vérifiées, corrigées et validées à chaque modification (comme avec les contrats en entreprise).



Je ne pensais pas que ça pouvait prendre autant de temps et dépendre d’autant de personne, sans compter les erreurs dans les compilateurs eux-même.



Le mieux au final serait de fabriquer d’abord son propre compilateur, pour ensuite programmer avec son propre code.








js2082 a écrit :



Le mieux au final serait de fabriquer d’abord son propre compilateur, pour ensuite programmer avec son propre code.





Même si on avait assez de temps pour le faire, il faudrait aussi fabriquer les CPU, vu que même eux sont bugués.









trekker92 a écrit :



les commentaires de 2show7, Patch, Inextenza, Konrad, Miles Prower et Soriatane (cf libristes intégristes) sont invités à s’expliquer sur l’argumentation infondée de leurs propos déversés dans les commentaires de l’article de cash investigation ici meme, on détient maintenant un argument béton que non, opensource/libre est et restera un gage d’adaptation vanté par Stallman, non un gage de sécurité : qui a le temps d’analyser l’entièreté du code source disponible sur la planete internet?







Un argument en béton ? Quoi, à cause d’une faille dans le noyau Linux ? Dans ce cas, vu le nombre de failles patchées chaque mois dans Windows, ça fait autant d’arguments en béton que Windows n’est pas du tout un gage de sécurité…



J’adore les gens qui, à partir d’un seul point de donnée, font une extrapolation à l’infini… <img data-src=" />



J’ai apporté des arguments ici même, en fournissant des liens vers des documents et des études détaillées. Tu peux lire mes commentaires précédents sur cette actu, et si tu n’es pas d’accord avec ce que je dis, merci d’apporter toi aussi des études chiffrées provenant de sources indépendantes (et pas uniquement tes « moi je crois que » habituels).









after_burner a écrit :



C’est pas parce que les failles ne sont pas encore exploitées à grande échelle que le danger est moindre.



D’ailleurs ils faudrait savoir comment sont comptabilisés les infections dans le cas d’abdroïd et de windows, une appli de type malware récupéré sur un store aura peut être tendance à passer plus inaperçue qu’un malware sur le net, voir à ne pas être considérée comme une application malveillante vue les différences d’usages entre un smartphone et un PC.







C’est ça que j’adore quand on parle de sécurité.



J’essaye d’apporter des données chiffrées, provenant d’études indépendantes, histoire qu’on parle de ce que l’on sait, au lieu de spéculer sur le mode « moi je crois que tel OS est mieux sécurisé ».



Et on me répond avec des épouvantails : « oui mais si ça se trouve il y a des failles et elles sont exploitées et on n’en sait rien ».



On ne va pas beaucoup avancer là…









Konrad a écrit :



C’est ça que j’adore quand on parle de sécurité.



J’essaye d’apporter des données chiffrées, provenant d’études indépendantes, histoire qu’on parle de ce que l’on sait, au lieu de spéculer sur le mode « moi je crois que tel OS est mieux sécurisé ».



Et on me répond avec des épouvantails : « oui mais si ça se trouve il y a des failles et elles sont exploitées et on n’en sait rien ».



On ne va pas beaucoup avancer là…







C’était pas pour pour savoir quel OS est mieux sécurisé, ça n’a rien à voir. Je dit que c’est pas parce que les failles ne sont pas utilisées qu’ androïd est plus sûr, puisque les failles sont là.



Et encore, même comme ça je ne suis même pas sûr que l’on soit à l’abri.

Le compilateur pourrait avoir un comportement inattendu lorsqu’il va pondre du code “optimisé” (pour le CPU) mais qui pourrait générer des scénario d’exploitation de faille alors que le travail en amont était nickel (le compilateur étant aussi bien fait).

L’association (l’enchainement) de plusieurs causes pourraient engendrer des réactions inattendues sur comment l’information sera manipulée et traitée au final.



Idéalement tout devrait être auditer et tester à fond - en long en large et en travers, mais c’est rarement le cas, surtout pour piloter des éléments non vitaux d’un système, ou du devenir de son utilisation.








Konrad a écrit :



vu le nombre de failles patchées chaque mois dans Windows, ça fait autant d’arguments en béton que Windows n’est pas du tout un gage de sécurité…







tout à fait, tu as enfin compris :

windows ou linux, le probleme de la sécurité ne dépend pas de l’accessibilité du code source mais des ressources disponibles pour les vérifier.

chez microsoft le nombre de produits est limité, les vérifier prend un temps certain avec des chercheurs dans un cadre limité.

dans le libre, la quantité de code source à vérifier évolue trop vite, le nombre de projets est tellement grand que meme une entreprise entière n’aurait pas le temps de tout valider “secure” donc non, le libre n’apporte pas de mesure de sécurité à cause des ressources humaines techniques, qui handicapent la vérification complète de tout le code source libre mondial.



La seule mesure de sécurité qu’apporte le libre c’est dans le déploiement plus rapide de correctifs.

Avec un logiciel libre on peut déployer un correctif avant même les mainteneurs du projet (c’est impossible avec un logiciel propriétaire).

C’est d’ailleurs souvent ce que font les distributions.

Le libre c’est aussi la seule solution face à obsolescence programmée. Un logiciel libre peut-être corrigé même lorsqu’il a été abandonné par ses auteurs.

Tous les logiciels comportent des bugs qui peuvent potentiellement devenir des failles (c’était le cas de ce bug sur Linux qui à l’origine n’était pas identifié comme une faille).

Personnellement je me sentirais toujours plus en sécurité sur des softs pour lesquels je sais que je peux “les réparer” en cas de besoin, plutôt que sur un soft pour lequel je serais à la merci de ses créateurs.

&nbsp;


ben si le disque dur n’est pas encrypté, oui








trekker92 a écrit :



le probleme n’est pas google

google est le premier a rendre disponible les mises à jour de son os android

le probleme est le nombre d’appareils à prendre en charge, est à la charge complete du fabricant (comme mac/iphone, pour apple) contrairement à un modele comme windows ou tout est à charge de microsoft pour simplifier.



ainsi, en connaissance de cause, je sais que mon zte blade s, déjà obsolete mais toujours sur les rails, que ma tablette lenovo, dans cinq ans, ne toucheront évidemment plus les mises à jour :

tant pis, j’ai compris que libre ou non libre l’enjeu reste le meme :

black hat, marché noir ou NSA (oui ca rime), tous peuvent avoir un droit de séjour illicite dans mon appareil, donc je ne met rien de sensible dedans. Le matelas est plus sécurisé la dessus.



ou est ce que je veux en venir?

depuis cette mode de l’ultra-connecté par le haut débit fixe et mobile, les utilisateurs n’ont pas pris conscience à réfléchir à la confiance à accorder à ces appareils, ils préfèrent taper sur un responsable (éditeur, développeur..) plutot que de s’abstenir, de se modérer afin d’éviter les conséquences d’une fuite de données personnelles.







Malheureusement, c’est bien la conception d’Android qui est responsable du problème.



Au lieu d’implémenter une solution de type Bios/UEFI et de définir un standard de compatibilité comme sur les PC avec gestion centralisée des drivers, ils ont utilisé un simple bootloader, ce qui oblige les fabricants a faire une version custom de l’os par modèle de machine. Et cela rends les mises à jour très difficiles…



Google a beau mettre à jour son OS, le travail que les fabricants doivent effectuer pour les répercuter sur leurs appareils est beaucoup trop important.



Cela explique le faible nombre de mises à jour et la durée de support limitée alors qu’une bonne distribution Linux sur PC reçoit quotidiennement des correctifs et qu’un PC peut recevoir de nouveaux Os pendant plus de 10 ans…









trekker92 a écrit :



windows ou linux, le probleme de la sécurité ne dépend pas de l’accessibilité du code source







Bien sûr que si : le fait que le code soit disponible fait que les correctifs sont développés et vérifiés beaucoup plus rapidement. On en a encore l’exemple ici : faille patchée 2 jours après sa découverte.



Renseigne-toi sur les time-to-patch en open et closed source…









doom_Oo7 a écrit :



ben si le disque dur n’est pas encrypté, oui



Pquoi tu veux mettre le disque dur dans une crypte? <img data-src=" />









-Stephane- a écrit :



La seule mesure de sécurité qu’apporte le libre c’est dans le déploiement plus rapide de correctifs.

Avec un logiciel libre on peut déployer un correctif avant même les mainteneurs du projet (c’est impossible avec un logiciel propriétaire).

C’est d’ailleurs souvent ce que font les distributions.

Le libre c’est aussi la seule solution face à obsolescence programmée. Un logiciel libre peut-être corrigé même lorsqu’il a été abandonné par ses auteurs.

Tous les logiciels comportent des bugs qui peuvent potentiellement devenir des failles (c’était le cas de ce bug sur Linux qui à l’origine n’était pas identifié comme une faille).

Personnellement je me sentirais toujours plus en sécurité sur des softs pour lesquels je sais que je peux “les réparer” en cas de besoin, plutôt que sur un soft pour lequel je serais à la merci de ses créateurs.







Il y a aussi plus de gens qui lisent le code d’un logiciel libre. Et contrairement à ce que certains affirment sans connaitre, ce n’est pas du tout une légende.












Patch a écrit :



Pquoi tu veux mettre le disque dur dans une crypte? <img data-src=" />







C’est plus efficace que de mettre une capote dessus <img data-src=" />



Bon. Il faut déjà avoir accès à la machine et avoir également le droit de compiler, ou à tout le moins ne pas avoir son /home monté en noexec. Ok c’est une vieille faille, mais c’est encore une faille qui nécessite d’avoir déjà accès et un certain nombre de droits à la machine. Avec un accès physique, n’importe qui peut faire n’importe quoi sur n’importe quel système.


Pourquoi faire un accès physique ? Y a plein d’autres moyen de propager du code véreux. Surtout sur des OS où les utilisateurs sont peu enclins à utiliser des antivirus.


Tu as aussi le problème de la plateforme utilisée dans les téléphones portables. De ce que j’ai cru comprendre une plateforme arm est absolument incompatible avec une autre plateforme arm et les concepteurs ne proposent pas de noyaux compatibles dans le temps.








sr17 a écrit :



C’est plus efficace que de mettre une capote dessus <img data-src=" />



<img data-src=" /> Spafo <img data-src=" />



Pour y accéder par la gloire du Saint Esprit








js2082 a écrit :



Je ne comprendrais jamais comment il peut y avoir autant de failles dans un système informatique.



 Si je suis bien, ces failles sont causées:

 - soit par des erreurs dans l’écriture du code: dans ce cas, c’est juste par qu’on s’est retrouvé avec un codeur qui sait pas écrire (le genre de chose qui peut se corriger avec de la rigueur)




  • soit par une organisation des processus mal fichus ou pensés de façon incomplète: dans ce cas, le travail est à finir.

     

    Du coup, j’ai du mal à comprendre comment un système ne peut pas ne pas devenir infaillible.







    L’Homme n’est pas infaillible, l’Homme écrit le système. Le système ne peut pas être infaillible.











trekker92 a écrit :



chez microsoft le nombre de produits est limité, les vérifier prend un temps certain avec des chercheurs dans un cadre limité.

dans le libre, la quantité de code source à vérifier évolue trop vite, le nombre de projets est tellement grand que même une entreprise entière n’aurait pas le temps de tout valider “secure” donc non, le libre n’apporte pas de mesure de sécurité à cause des ressources humaines techniques, qui handicapent la vérification complète de tout le code source libre mondial.&nbsp;





Tu délire un peu. Dans l’open Source il a comme même des boites qui développent des logiciels et ont tout intérêt à ce que cela ne part dans tous les sens, sinon c’est des tonnes de personnes à mettre en maintenance. Là dessus, je pense que des grosse boîtes comme Intel, Google ou Red Hat ont des procédures similaires à MS pour produire du code, le vérifier et l’auditer.







trekker92 a écrit :



que même une entreprise entière

n’aurait pas le temps de tout valider “secure”&nbsp;



&nbsp;

C’est bien pour cela que les entreprises ont mutualisé leur ressources. Il n’ y a pas qu’une seule entreprise sur le projet Linux, mais une fondation: regarde la liste. Peux-tu m’expliquer ce que vient faire dans Linux DreamWorks et Toyota ou encore Goldman Sachs??

Faire de la R&D tout seul dans leur coin sur des projet complexe c’est pas toujours opportun. Regarde les partenariats dans l’aéronautique, l’automobile, dans la santé le séquençage du génome humain a été une œuvre mutualisée et communautaire. Pas l’affaire d’un seul professeur Tournesol dans son laboratoire.









trekker92 a écrit :



opensource/libre

est et restera un gage d’adaptation vanté par Stallman, non un gage de

sécurité : qui a le temps d’analyser l’entièreté du code source

disponible sur la planète internet?





Stallman a

toujours parlé de liberté de l’utilisateur, jamais de la sécurité.

Désolé si certains confonde l’Open Source et le Logiciel Libre.



Après la sécurité est basé sur la confiance et pour moi avoir la recette d’un logiciel est un gage de confiance plus fort qu’une certification ISO machin de bonne procédure de production de code.









thomgamer a écrit :



Ubuntu je sais pas, ma dernière Buntu remonte à 10.4, mais Android je sais qu’il y avait eu un patch de sécurité qui apporté une faille qui a donc du être repatché mais c’était plus tordu que ça, le patch faisait qu’en apparence android n’était plus touché par cette faille mais c’était que du pipeau <img data-src=" />





Un patch volkswagen donc ?



En nombre absolu, Linux à bien plus de développeurs je pense.&nbsp;








Soriatane a écrit :



Tu délire un peu. Dans l’open Source il a comme même





<img data-src=" />

Ça coupe l’envie de lire plus loin…









Cashiderme a écrit :



Pourquoi faire un accès physique ? Y a plein d’autres moyen de propager du code véreux. Surtout sur des OS où les utilisateurs sont peu enclins à utiliser des antivirus.





Es-tu sûr de bien avoir lu mon post, articulé en différentes phrases, avant de poster ta réponse ?









trekker92 a écrit :



tout à fait, tu as enfin compris :

windows ou linux, le probleme de la sécurité ne dépend pas de l’accessibilité du code source mais des ressources disponibles pour les vérifier.

chez microsoft le nombre de produits est limité, les vérifier prend un temps certain avec des chercheurs dans un cadre limité.

dans le libre, la quantité de code source à vérifier évolue trop vite, le nombre de projets est tellement grand que meme une entreprise entière n’aurait pas le temps de tout valider “secure” donc non, le libre n’apporte pas de mesure de sécurité à cause des ressources humaines techniques, qui handicapent la vérification complète de tout le code source libre mondial.





Argument qui ne tiens pas la route pour la simple est bonne raison que ta comparaison est erroné. Tu compares Microsoft qui est en effet une entreprise a des licences logicielle. Autant comparer des poires et des avions. Ca n’a simplement aucun sens.



Je ne comprends pas, selon la page https://security-tracker.debian.org/tracker/CVE-2016-5195 la vulnérabilité est corrigée pour Stretch mais pourtant la dernière version disponible n’est pas la version corrigée (https://packages.debian.org/stretch/linux-image-amd64)








Soriatane a écrit :



&nbsp;



Après la sécurité est basé sur la confiance et pour moi avoir la recette d'un logiciel est un gage de confiance plus fort qu'une certification ISO machin de bonne procédure de production de code.





Ce qui démontre bien que la “confiance” est une croyance irrationnelle, puisqu’une faille critique d’un logiciel open source peut&nbsp;mettre de très nombreuses années avant d’être découverte. Cette actualité le démontre, mais beaucoup d’autres aussi (ex. : l’audit récent du code de VeraCrypt qui a permis de découvrir des failles).



AMHA, quand t’es la NSA, c’est pas plus compliqué de t’infiltrer dans les groupes de développement des logiciels open source pour y intégrer discrètement des failles de sécurité, que d’essayer d’imposer à une multinationale comme Microsoft d’intégrer volontairement des portes dérobées dans son code et de fermer sa gueule… La NSA le fait-elle ? Le cas échéant,&nbsp;la pratique est-elle fréquente ? J’en sais rien, et toi non plus. Les leaks de Snowden&nbsp;& co ne démontrent pas grand chose, si ce n’est que les moyens utilisés par la NSA pour arriver à ses fins sont sans limite, avec ou sans le concours des développeurs. Au final il n’y a pas plus de raisons objectives de faire confiance à un logiciel open source qu’à un logiciel closed source, sauf si on a vérifié soi même chaque ligne de code du logiciel open source, ce qui est impensable dès qu’on dépasse un certain volume.



C’est quand même plus simple de dire a MS d’inclure des backdoors dans leurs logiciels et de leur filer les accès, plutôt que de se faire chier a aller dans chaque groupe de devs des distributions existantes pour leur ajouter des failles.



Après les deux sont faisables jsuis bien d’accord mais pas aussi simple.

D’ailleurs Quid de Canonical et la NSA? Ils n’auraient pas de coopération entre eux aussi?


Je suis d’accord avec toi que la NASA peut infiltrer des groupes de développeur Open Source pour y intégrer des failles. Infiltrer des gens dans une structure ennemie, c’est le boulot des agences d’espionnage.



Ma confiance dans le logiciel libre vient dans son contrat juridique. Je peux dès le départ (et si j’ai la volonté et les ressources finnancière) dire merde à tout le monde et reprendre le logiciel à mon propre compte.



Avec les logiciels propriétaires, je ne peux rien faire (même pas nationaliser pour les plus extrémistes). Je perds ma souveraineté.


Ce qui est certain aussi c’est que Snowden utilise GNU/Linux au quotidien.

Ce qui est certain aussi c’est que les paquets qui sortent d’une machine GNU/Linux tu peux les analyser un par un, sans avoir à déchiffrer certains de ces paquets cryptés par l’OS lui même (comme le fait l’étrange Advapi.dll).








CaptainDangeax a écrit :



Es-tu sûr de bien avoir lu mon post, articulé en différentes phrases, avant de poster ta réponse ?







Oui j’ai tout lu. Alors si tu veux, il n’y a pas plus besoin d’avoir droit de compiler que d’avoir accès physique à la machine. Quant au home en noexec, à part cas particulier, qui fait ça ? Je serais bien emmerdée avec ça en ce qui me concerne. Et sur mon tel Android je fais comment ? Et sur mon routeur ?



Linux, ça n’est pas que les gnu-like, et un binaire peut très bien trimbaler du code malsain.



Ou alors j’ai rien pigé à ce que tu voulais dire, mais il me semble que tu sous-estime la dangerosité de la faille, quand meme.









Soriatane a écrit :



Tu délire un peu. Dans l’open Source il a comme même…





Aïe… correcteur orthographique open ou closed source?&nbsp; <img data-src=" />



Edit : BBQed









vampire7 a écrit :



<img data-src=" />

Ça coupe l’envie de lire plus loin…





ils restent soft dans la définition (j’admire la pudeur du “en raison d’une mauvaise compréhension du mot” <img data-src=" /> )









Pr. Thibault a écrit :



Ce qui démontre bien que la “confiance” est une croyance irrationnelle







Non. La confiance, ça peut être irrationnel, mais ça n’a pas obligatoirement à l’être.



Typiquement quand on parle de produits ou services que l’on utilise : tu commences par souscrire à un service dans une entreprise A. Si tout se passe bien (tu es content du service, du rapport qualité/prix…), alors tu vas avoir confiance dans l’entreprise A. Si quelque chose se passe mal (coûts cachés, service souvent interrompu, etc.), alors ta confiance sera brisée et tu iras voir ailleurs. C’est très rare que quelqu’un ait confiance en une entreprise ou un produit sans raison, de façon irrationnelle.



La confiance est généralement basée sur l’expérience que tu as avec un produit ou un fournisseur.



La confiance est subjective (différentes personnes n’auront pas la même expérience, et donc n’accorderont pas la même confiance à un produit donné), mais elle n’a pas forcément à être irrationnelle.









Pr. Thibault a écrit :



puisqu’une faille critique d’un logiciel open source peut mettre de très nombreuses années avant d’être découverte.







Ben oui et c’est le cas aussi dans des logiciels closed-source… Donc ça ne démontre rien du tout.









Pr. Thibault a écrit :



AMHA, quand t’es la NSA, c’est pas plus compliqué de t’infiltrer dans les groupes de développement des logiciels open source pour y intégrer discrètement des failles de sécurité, que d’essayer d’imposer à une multinationale comme Microsoft d’intégrer volontairement des portes dérobées dans son code et de fermer sa gueule…







Mais d’où tu sors des trucs pareils ?



Regarde les faits en face : on SAIT de source sûre que Microsoft a collaboré avec la NSA, facilitant l’accès à Outlook et à Skype notamment. Du côté de l’Open Source, on sait quoi de façon sûre ? Rien du tout. Personne n’a jamais démontré qu’il y avait des agents de la NSA qui inséraient du code en douce dans les logiciels libres…



Et toi, tu avances des choses en mode « théorie du complot » : peut-être que des agents de la NSA contribuent en douce, peut-être qu’il y a des backdoors dans Linux et on ne le sait pas… Ouais, et peut-être qu’au lieu d’inventer des épouvantails et de faire du FUD, tu devrais t’en tenir simplement aux faits, tu n’arriverais pas aux mêmes conclusions, non ?









Pr. Thibault a écrit :



La NSA le fait-elle ? Le cas échéant, la pratique est-elle fréquente ? J’en sais rien, et toi non plus. Les leaks de Snowden & co ne démontrent pas grand chose







Allez hop là, on balaye tous les documents révélés par Snowden d’un revers de la main… <img data-src=" />









Pr. Thibault a écrit :



Au final il n’y a pas plus de raisons objectives de faire confiance à un logiciel open source qu’à un logiciel closed source, sauf si on a vérifié soi même chaque ligne de code du logiciel open source, ce qui est impensable dès qu’on dépasse un certain volume.







Je compare les logiciels libres avec les publications scientifiques. Les scientifiques publient leurs résultats dans des revues internationales, ce qui implique les étapes suivantes : (1) co-écriture de l’article par plusieurs auteurs, en détaillant leur protocole (le « code source ») et leurs résultats ; (2) lecture par l’éditeur du journal ; (3) relecture et critique par des chercheurs indépendants ; (4) modification, amélioration ; (5) si l’article est accepté, il est rendu public, et les travaux peuvent être lus, reproduits, et modifiés/adaptés par d’autres laboratoires.



Les scientifiques ont confiance dans les résultats publiés, car ils passent par toutes ces étapes de validation. Le fait que le protocole soit détaillé, que toutes les données soient disponibles et publiques, leur donne une raison objective d’avoir confiance dans les résultats publiés (*). Pourtant, chaque scientifique ne va pas refaire l’expérience lui-même ; mais il a confiance, car la publication a été validée par des spécialistes, les auteurs ont dû dévoiler leur méthodologie, ils ont dû s’exposer aux critiques de leurs confrères et du grand public : pour cela, la majorité des autres scientifiques ont confiance. Et ceux qui n’ont pas confiance peuvent, s’ils le souhaitent, reproduire l’expérience : si leurs résultats sont identiques ils auront confiance, et s’ils sont différents alors ils dénonceront la supercherie.



Typiquement, si des gens annoncent des résultats spectaculaires (une nouvelle planète, de nouvelles lois physiques, le clonage humain ou autre), sans donner leur protocole expérimental, sans préciser comment ils ont fait, ni dans quelles conditions, bref si l’expérience est impossible à reproduire : alors ce n’est pas de la science, et l’immense majorité des scientifiques rejettera ce résultat, car ils n’auront pas confiance. Le fait qu’une expérience soit reproductible est un critère objectif pour avoir confiance.



Je trouve que le parallèle avec les logiciels libres est criant. Les logiciels libres sont (1) co-écrits par plusieurs développeurs ; (2) relus et audités par d’autres développeurs ; (3) rendus publics ; (4) ils peuvent être testés, vérifiés, modifiés par d’autres développeurs, y compris par des concurrents ! Ça aussi c’est important : souvent, les logiciels libres sont co-développés par des entreprises qui sont en concurrence directe, comme Red Hat/Canonical ou encore AMD/Intel pour le noyau Linux. Si une entreprise (ou un agent planqué de la NSA) insérait du code malveillant, ça serait du pain béni pour la concurrence ! De quoi bien enfoncer l’entreprise fautive, et la faire sortir à jamais du circuit des logiciels libres…



Et ça, ce sont autant de raisons objectives d’avoir davantage confiance dans les logiciels libres, que dans les logiciels propriétaires.





(*) Les fraudes scientifiques sont possibles, mais elles restent très rares ; et elles finissent toujours par être découvertes, quand plusieurs laboratoires essayent de reproduire des résultats publiés et se rendent compte que ça ne colle pas du tout.



Pour moi, le problème est aussi le conflit d’intérêt.



Chez Microsoft, s’ils ont intérêt à introduire une faille ou à espionner leur client, ils ne vont certainement pas engager des experts pour vérifier si ces failles existent et les corriger.

Même chose pour la découverte de failles gênantes: une fois que l’expert montre la faille, il faut investir des ressources dans son patch, et il existe des centaines de situations où ça ne sera pas la priorité. Surtout que trouver une faille en interne et ne pas la corriger n’est pas un problème: si quelqu’un d’autre la trouve, ce n’est pas une preuve d’incompétence puisqu’on peut toujours dire que la faille n’avait jamais été vue en interne en argumentant que personne n’est à l’abri des failles (la preuve: linux avait une faille vieille de 9 ans).



L’intérêt de l’Open Source, c’est que ceux qui vérifient le code sont indépendant, voire parfois même en concurrence, avec le créateur initial du code.

À ce niveau, il n’est même pas nécessaire que tout le code soit lu: le simple fait qu’on autorise autant de transparence dans le code open source fait que créer du code volontairement malveillant est difficile et incertain (oui, certaines faille ne sont pas vues avant des années, mais d’autres sont vues le lendemain de leur introduction).

Par exemple, comment la NSA peut-elle s’y prendre ?

Soit elle essaie de recruter un développeur déjà bien impliqué, ce qui implique de très très gros risques que le développeur va dénoncer l’acte de la NSA (d’un côté, les libristes sont très soucieux de la vie privée, donc, peu de chance qu’un développeur soit idéologiquement d’accord pour faire ça, et de l’autre, un développeur va sans doute facilement savoir comment utiliser le net anonymement pour avertir les gens).

Soit elle infiltre le groupe de développeurs, mais dans ce cas, le développeur infiltré devra d’abord grimper les échelons en produisant du bon code, arriver à se trouver dans une position où une faille est utile (créer une faille dans le driver d’une imprimante des années 80, cela n’est pas utile), arriver à trouver une faille qui a l’air d’être de bonne foi (tu ne peux pas écrire “if (backdoorkey == “nsa”) then set_uid(0)“), et prier pour qu’elle ne soit pas découverte le lendemain.

&nbsp;


A lire tous ces commentaires, on a l’impression qu’un “libriste” est un peu comme un ange venu des cieux, et qui réalise du code pour purger ces mécréants que sont les solutions closed-source.

Euh non, un libriste n’est pas forcément soucieux de la vie privée. Un libriste ne va pas faire de la charité.Quand un libriste relit du code, il peut passer à côté de failles.



On met un peu trop de responsabilités sur les libristes comme vous dites, mais regardez un peu les stats de github; qui contribue énormément aux logiciels libres ?

Des anges de la vie privée bien sûr !

&nbsp;Il suffit d’aller faire un tour sur :https://octoverse.github.com/

Hum, ces anges de la vie privée s’appellent : Microsoft, Facebook et Google…

&nbsp;Huum, y a pas comme un pépin ?!



Et un backdoor c’est pas du code écrit en dur avec des constantes débiles donc bon courage pour vérifier tout ca.

Il suffit qu’un dev construise une élévation de privilège sur des mois et des mois, avec le bon enchaînement dans un workflow précis et ça devient indétectable. Donc bref, logiciels libres ou pas c’est le même combat : il y a des failles, il faut les corriger le plus rapidement, et surtout; SURTOUT : les diffuser aux utilisateurs.



Et là, carton rouge Androïd… Un des seuls OS avec un support technique avec une moyenne pitoyable… Mais il est pas en partie open source Androïd ?








Shyfer a écrit :



On met un peu trop de responsabilités sur les libristes comme vous dites, mais regardez un peu les stats de github; qui contribue énormément aux logiciels libres ?

Des anges de la vie privée bien sûr !

 Il suffit d’aller faire un tour sur :https://octoverse.github.com/

Hum, ces anges de la vie privée s’appellent : Microsoft, Facebook et Google…

 Huum, y a pas comme un pépin ?!







Dans le cas de logiciels propriétaires : Microsoft développe son code dans son coin et personne d’autre ne peut le voir. Facebook développe son code dans son coin et personne d’autre ne peut le voir. Et ainsi de suite. Donc, si un bout de code est mal fichu, si une routine est mal conçue ou buggée, personne d’autre ne peut le voir ni le corriger pendant le développement. Si Microsoft ajoute du code sur demande de la NSA, personne ne peut s’en apercevoir. C’est la magie du Closed Source, tout se passe en vase clos, tout le développement est opaque.



Dans le cas de logiciels libres : Microsoft contribue à un projet, son code peut immédiatement être relu et audité par Google, par Red Hat, Canonical, ou n’importe qui d’autre. Google contribue à un projet : son code peut aussi être audité par Microsoft, Canonical, Intel… Bref les concurrents sont censés veiller au grain. Donc si une routine est développée à l’arrache, avec des mauvaises déclarations ou quoi, ça se voit tout de suite. Et crois-moi, si Red Hat pouvait attaquer Canonical sur ses contributions, ou si Google pouvait dire que Microsoft a fait de la merde, ils ne se gêneraient pas.



Humm, tu vois un peu la différence ou pas ?









Shyfer a écrit :



Et là, carton rouge Androïd… Un des seuls OS avec un support technique avec une moyenne pitoyable… Mais il est pas en partie open source Androïd ?







Oui, et les infections sur Android sont dûes à quoi ? Quasiment exclusivement à des applis tierces téléchargées depuis le Store (ou depuis des Stores alternatifs).



Et pas à des failles dans les composants Open Source…



J’imagine qu’il y a pas mal d’éléments qui sont une réponse à mon commentaire.



Tout d’abord, mon commentaire est lui-même une réponse, il pousse donc le balancier du côté opposé à celui où il a été poussé.

Si un premier commentaire dit que tout les chats sont noirs, le second commentaire insistera sur l’existence de chats qui ne sont pas noirs, mais cela ne veut pas dire que l’auteur n’est pas au courant que les chats noirs existent bel et bien.



À propos du respect de la vie privée: c’est une bonne remarque, mais cela reste vrai qu’une partie des développeurs adhèrent à certaines valeurs. C’est d’autant plus vrai dans les outils sensibles, qui sont justement développé la plupart du temps en réponse à des solutions qui, selon les développeurs, ne donnent pas suffisamment de garantie là dessus.



À propos de la backdoor: tu dis exactement ce que je dis: alors que pour du close-source, un bête code écrit en dur suffit (avec 2-3 précaution, certes, mais s’il saute au yeux dans le code source, ce n’est pas un problème), dans le cas open-source, si on veut intentionnellement introduire une faille, il faut s’impliquer des mois et des mois, et trouver une manière intelligente de le faire, et avoir la chance d’être en position de justifier le changement (par exemple, si j’ai un exemple de faille invisible dans la partie X du code, mais que cette partie fonctionne très bien et que mon exemple n’apporte aucune amélioration des performances, ma modification ne sera pas acceptée).

Bref, c’est totalement possible, mais c’est bel et bien beaucoup plus compliqué, et on ne peut pas sérieusement nier ça.

&nbsp;


Si tu lis bien la page que tu mets en lien, il y a marqué vulnerable en rouge en regard de Jessie, ce qui veut dire que la version dans le dépôt n’est pas patchée. A contrario, la version présente dans le dépôt jessie (security) (debhttp://security.debian.org/ jessie/updates main contrib non-free)est patchée.



Il me semble l’avoir indiqué plus haut dans les commentaires, sans doute pas assez clairement.








wanou2 a écrit :



Tu as aussi le problème de la plateforme utilisée dans les téléphones portables. De ce que j’ai cru comprendre une plateforme arm est absolument incompatible avec une autre plateforme arm et les concepteurs ne proposent pas de noyaux compatibles dans le temps.







Deux PC qui ont des composants complètement différents sont dans la même situation.



Sauf qu’il y a un bios/uefi qui joue le rôle de couche d’abstraction matérielle. Au moins le temps pour l’Os de pouvoir booter et de trouver des drivers plus adéquats.



Après, le fait que la compatibilité des PC soit érigée en norme permet effectivement de respecter une certaine normalisation sur le plan du matériel.



Le tort de Google en lançant Android a été de ne pas définir de standard de compatibilité au départ.



Et il n’est pas sûr que quelqu’un arrive à remédier à la situation maintenant.



A long terme, cela pourrait entraîner l’échec des plateforme ARM et le retour d’intel, du x86 et de l’architecture du PC pour les mobiles.









Cashiderme a écrit :



Oui j’ai tout lu. Alors si tu veux, il n’y a pas plus besoin d’avoir droit de compiler que d’avoir accès physique à la machine. Quant au home en noexec, à part cas particulier, qui fait ça ? Je serais bien emmerdée avec ça en ce qui me concerne. Et sur mon tel Android je fais comment ? Et sur mon routeur ?



Linux, ça n’est pas que les gnu-like, et un binaire peut très bien trimbaler du code malsain.



Ou alors j’ai rien pigé à ce que tu voulais dire, mais il me semble que tu sous-estime la dangerosité de la faille, quand meme.





Il faut tout de même avoir la possibilité d’importer un exécutable infecté sur la machine, et l’exécuter. Tout le monde n’a pas ces droits. Peut-on importer facilement et lancer un exécutable sur ton routeur ? Oui, alors tu as un problème mais pour une fois, il n’est pas dans l’interface chaise clavier mais plutôt dans l’interface carte de crédit vendeur. C’est vrai qu’Android est un gruyère, déjà pour commencer par l’utilisation de VFAT au lieu d’un fs du monde Unix .



L’orthographe est correcte ;)








CaptainDangeax a écrit :



Android est un gruyère, déjà pour commencer par l’utilisation de VFAT au lieu d’un fs du monde Unix .





Je viens de vérifier à l’instant sur mon MotoX: “adb shell mount” me montre que c’est ext4 qui est utilisé

C’est une exception?



Si tu avais lu mon commentaire tu aurais vu que je parlais de Stretch et non de Jessie. Mais merci pour ton intervention.


Désolé, j’utilise plutôt Sid pour désigner Unstable, du coup j’ai mal interprété la question. La bonne réponse est que la version du noyau dans linux-image-4.7.0-1-amd64 est bien 4.7.8-1 (le numéro dans le nom du paquet ne reflète pas la version du noyau).


La NSA ajoute pas mal de truc dans Linux en fait, et bah personne n’est capable de dire quelle sont les implications réel simplement parce qu’à partir d’un moment la complexité du code rend son analyse impossible. Surtout en codant des OS avec des langages à effet de bord et non déterministe comme C/C++. La seule façon d’avoir un OS sécurisé et de laisse tomber quasi&nbsp;complètement les archi moisie des années 70 et de tout repenser de 0, en utilisant des&nbsp;processus scellés, des contrats signés, en interdisant la mémoire partagée etc. En isolant, les applis dans des micro VM.



Tu peux regarder les sources de Singularity pour ça OS expérimentale de MS sur le sujet. Ou encore Barelfish.








teddyalbina a écrit :



La NSA ajoute pas mal de truc dans Linux en fait, et bah personne n’est capable de dire quelle sont les implications réel simplement parce qu’à partir d’un moment la complexité du code rend son analyse impossible.









  1. La NSA contribue effectivement dans Linux, ce n’est pas nouveau, ça date au moins de 2003 voire avant. Rien de secret là-dedans, pas d’espion qui se serait déguisé ni infiltré… Ils font ça de façon tout à fait ouverte, et leurs commits sont clairement estampillés et visibles de tous.



  2. La NSA contribue surtout aux modules SELinux, et principalement… parce que la NSA utilise elle-même Linux et qu’elle veut se protéger. On pense souvent à la NSA qui espionne les autres, mais la NSA (et les autres agences américaines) sont aussi des cibles d’attaques, il est donc naturel qu’elles s’impliquent dans des modules de sécurité. Alors oui, peut-être que la NSA a mis des backdoors dans SELinux (ou d’autres partie du noyau), mais on sait très bien qu’une backdoor n’est pas réservée à son créateur : n’importe qui trouvant la faille peut l’exploiter. Donc, en mettant une backdoor dans un OS qu’elle utilise, la NSA se rendrait elle-même (et les autres agences, et tous ses agents qui utilisent Linux ou Android) vulnérables à un éventuel pirate (ou une autre agence) qui pourrait aussi exploiter cette backdoor. Une agence de sécurité et d’espionnage prendrait-elle un tel risque ? Pas sûr.



  3. Peut-être que le code est complexe à relire. Ça n’empêche qu’il est relu et audité par d’autres : la NSA n’ajoute pas du code dans Linux sans supervision hein… D’autres développeurs -y compris chez les autres grandes puissances comme la Chine- relisent et testent le code source. La Chine veut arrêter d’utiliser Windows car ils veulent l’indépendance numérique, et ils se tournent vers Linux : tu penses bien que s’ils trouvaient le moindre problème, ils se feraient un plaisir d’en faire un gros scandale…



  4. Peut-être que la NSA a mis une backdoor et que pour l’instant elle n’a pas été découverte. Mais si un jour elle est découverte, on saura qui a développé ce code (les commits sont suivis hein), et la NSA se verra exclue de tout projet Open Source.



  5. Si tu crois que les failles sont découvertes en lisant le code source, tu te trompes. La plupart du temps elles sont découvertes en faisant tourner l’appli, et en analysant ce qui entre et sort par le réseau par exemple. Jusqu’à aujourd’hui, aucune donnée suspecte n’a été repérée sous Linux… Et pourtant s’il y a des ordinateurs dont le réseau est étroitement surveillé (et par différentes entités partout dans le monde), ce sont bien les serveurs sous Linux. Rien n’a jamais été détecté, nulle part.



  6. Dans la majorité des distributions grand public, SELinux n’est pas activé. Donc ce n’est pas avec ça que la NSA risque d’espionner massivement la population…



    Conclusion générale : l’argument « peut-être qu’il y a une backdoor et on ne le sait pas », c’est du FUD, c’est de la théorie du complot. C’est du même niveau que de dire : « personne n’a jamais vu d’éléphant rose voler, mais si ça se trouve ça existe, tu ne peux pas prouver le contraire ». Une fois que tu as dit ça, tu n’as rien dit, tu n’as rien démontré. Tu as juste essayé de faire peur aux gens, de les faire douter : c’est du FUD pur et dur.



    Oh, tu peux bien inventer d’autres arguments du même acabit pour contrer mes arguments ci-dessus : « la faille est peut-être discrète », « ça peut être une faille dormante que la NSA n’a pas encore activé », « peut-être qu’ils collaborent avec les chinois pour développer des backdoors »… Ouais, et peut-être qu’un éléphant rose vole au-dessus de chez toi en ce moment et tu ne le vois pas : tu ne peux pas me prouver le contraire. Tous ces arguments que tu peux sortir ne sont que des « peut-être ». Des inventions, rien de concret. Si tu viens nous donner des preuves concrètes, les lignes de code incriminées, les traces réseau qui démontrent qu’il y a un problème, là oui on t’écoutera. En attendant toutes ces suppositions sorties de ton chapeau ne sont que du FUD.



    Par contre, le fait que Microsoft a collaboré avec la NSA, et lui a facilité l’accès à Outlook et à Skype pour espionner les gens (y compris des américains), ça ce sont des faits avérés, révélés par Snowden. Ce ne sont pas des suppositions tu vois, ce n’est pas du « peut-être ». C’est du concret, du solide, des FAITS. Mais j’imagine que tu es davantage méfiant envers les contributions de la NSA à Linux, qu’envers ton Windows que tu utilises tous les jours. Si c’est le cas, alors ta confiance en Windows n’a rien d’objectif ni de raisonné : c’est une confiance irrationnelle.









    teddyalbina a écrit :



    Surtout en codant des OS avec des langages à effet de bord et non déterministe comme C/C++. La seule façon d’avoir un OS sécurisé et de laisse tomber quasi complètement les archi moisie des années 70 et de tout repenser de 0, en utilisant des processus scellés, des contrats signés, en interdisant la mémoire partagée etc. En isolant, les applis dans des micro VM.



    Tu peux regarder les sources de Singularity pour ça OS expérimentale de MS sur le sujet. Ou encore Barelfish.







    Certes, je suis bien d’accord. Mais pour l’instant il n’existe aucun OS sur le marché qui réponde à ce que tu décris.









teddyalbina a écrit :



La NSA ajoute pas mal de truc dans Linux en fait, et bah personne n’est capable de dire quelle sont les implications réel simplement parce qu’à partir d’un moment la complexité du code rend son analyse impossible.







Faux.



D’abord, il y a quantité des personnes qui savent très bien relire et analyser du code en C.



Ensuite, la communauté du logiciel libre est logiquement très méfiante vis a vis de code qui proviendrait de la NSA.





Surtout en codant des OS avec des langages à effet de bord et non déterministe comme C/C++. La seule façon d’avoir un OS sécurisé et de laisse tomber quasi complètement les archi moisie des années 70 et de tout repenser de 0, en utilisant des processus scellés, des contrats signés, en interdisant la mémoire partagée etc. En isolant, les applis dans des micro VM.



Tu peux regarder les sources de Singularity pour ça OS expérimentale de MS sur le sujet. Ou encore Barelfish.





Pourquoi personne ne fait tout cela ? Tout simplement parce que ça se payerait cher sur le plan des performances.



Cela fait des décennies qu’on pense que les micro noyaux et services isolés seront peut être le futur. Mais des expériences comme Hurd n’ont pas eu le succès escompté. Trop lent…



Quand aux langages “sécurisés”, autrement dit avec “bound checking” tels que Java ou C#, ils ont un coût en performances et ne permettent pas pour autant d’éviter toute faille.



En dehors des services hautement sensibles, personne n’est prêt à abandonner la performance pour plus de sécurité.



Si on veut réellement faire quelque chose pour la sécurité, c’est beaucoup plus simple que d’inventer de nouveaux os ou concept compliqués : il faut que tout appareil connecté au web soit mis à jour en temps réel. Par exemple, les smartphones sous Android qui ont une base Linux devraient pouvoir recevoir des correctifs quotidiennement comme toutes les bonnes distributions.



Les moyens ne sont pas que humain :)

en l’occurrence c’est ce dont je parlais :)