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.
Commentaires (163)
Neuf ans, comme quoi, code visible ou pas, personne n’est à l’abri.
" />
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é ? 
" />
Je vais faire les màj qui s’imposent, mais j’aime bien vérifier que les failles sont bien bouchés
Alors monsieur Torvalds Linus on fait quoi ?
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.
Pire, imagine 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 
" />
" />
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.
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 !
:grabpopcorn:
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).
Have Fun :https://packetstormsecurity.com/files/139287/cowroot.c
HAPPEAU ????
Réponse de Linus Torvalds : C’est la faute de Nvidia ?
" />
‘dredi
Il répond avec calme et sénérité, comme d’hab
" />
*So Fuck You nVidia*
Bien tenté , en plus on est vendredi, donc tu as le droit
" />
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.
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)
Du coup, j’ai du mal à comprendre comment un système ne peut pas ne pas devenir infaillible.
oh la la comme il m’a cassé mon délire du vendredi 
" />
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
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 !
aille… android est un kernel linux…
Donc le nsa a cette faille depuis 8 ans.
Si ce n’est plus et comme la politique de mise à jour de android est déplorable à part sur certain modèles, ça pique grave….
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.
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 ?
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
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
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 ?
IBM et la gestion de la mémoire, c’est tout un poème… entre GPFS qui alloue massivement des physical pages (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
" />
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.
Comme quoi, JVachez était un visionnaire !
Moi aussi je vais apporter ma contribution, mais je vais être plus soft 
" />
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.
" />
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…
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).
Il te faut quoi pour que ça soie un mea culpa à tes yeux ??
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?
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 ?
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…
" />
Sinon je comprends pas, le code est pourtant limpide (j’adore le C :) )
#include <stdio.h>
#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) _<::> \(\_\)_ <%
,_\((), \_\)(),_\((),\_\)(),_\(() ,\_\)(), __( ‘,’,‘,’,‘,’ ,‘,’ ,‘,’) * _\(\_() ,( \_\)_()
__(’_’,’_’, ‘_’,’_’, ‘_’)*__(’_’,’_’, ‘_’,’_’, ‘_’)+__(’_’,’_’, ‘_’,’_’ , ‘_’)
,__(’_’,’_’,’_’,’_’,’_’,’_’,’_’,’_’,), _\(() m(i,a,u)(\)(n,i,t) \(\_)<% \)_ (f,i) (
\(\_ \)_(=,=) __(_) ) \(\_\)(\(\_(f,i)(\_[ \_\)_()____(_,_) ]>_[ _\(\_()] )\_[\_\)_()____ (_,_
,_,_,_,_,_)] \(\_\)_ __(_) )\(\_(f,i)(\_[\_\)_()____(_ ,_ ,_)] >_[ _\(\_()+ \_\_\)() ] ||
_[_\(\_()\_\_\_\_(\_,\_,\_,\_,\_,\_,\_)] \)_ (=,=) __\(()) r(e,t) \_[\_\_(\_,\_,\_ ,\_,\_ ,\_)] \)_\(\_ \_
[\_\_ (\_,\_,\_,\_,\_,\_,\_)\_\_\_\_(\_,\_,\_,\_,\_,\_) ]/\_[\_\_(\_,\_,\_,\_,\_) \_\_\_\_(\_,\_,\_,\_,\_,\_)]\*( \_[
\_\_\)()]-_[_\(()])+\_[ \_\)() ];_[__(_,_,_,_,_,_,_)] \(\_\)_ _[__(_,_,_,_,_,_,_) ____
(_,_,_,_,_)]/_[_\(\_()]\*(\_[\_\_(\_,\_,\_,)]-\_[\_\_(\_,\_,)] )+\_[\_\_(\_,\_,)];\_[\_\_(\_,\_,\_,\_, \_
,\_,\_,\_)] \)_\(\_ \_[\_\)_() - __\(()] \)_\(\_ \_[\_\_(\_,\_,\_,\_,\_)+ \_\)_()-__\(()] \)_\(\_ \_\)();
_f:_[__(_,_,_,_)] \(\_\)_ _[__( _,_,_,_, _,_,_, _)] * _ [__(_,_,_, _,_,_,_,_)];
_[__(_,_,_,_,_)] \(\_\)_ _[_\(\_() - \_\_\)()]*_[_\(\_() - \_\_\)()];_[__(_,_,_,_,_,_,_,_,_
)] \(\_\)_ __(_,_)*_[__(_,_,_,_,_,_,_,_)]*_[_\(\_() -\_\_\)()]+ _[__ (_,_,_,_,_,_,_)];
_[__(_,_,_,_,_,_,_,_)] \(\_\)_ _ [ __(_,_,_,_) ]-_[__(_,_,_,_,_)]+_[__(_,_,_,_,_,
_)];\(\_\)(_[_\(\_()\_\_\_\_(\_,\_,\_,\_,)]++)\)_(f,i)((_ [_\(\_() \_\_\_\_ (\_,\_,\_,\_,)]< \_ [\_\)_ ()
____ (_,_,_,_,_)])&&(_[__(_,_,_,_)]+ _[__(_,_,_,_,_)]<_[_\(\_()\_\_\_\_(\_,\_,\_,\_,\_,\_)
])) \)_(to,go) _f; \(\_(ar,ch) \)(m,i,au)[] \(\_\)_ <% __(_,_,_) * _\(\_()\_\_\_\_(\_,\_), \_\_
(\_,\_,\_,\_) \* \_\)_()____(_,_,_),__(_,_,_,_,_,_) * _\(\_()\_\_\_\_(\_,\_,\_,\_), \_\_(\_,\_,\_,\_)
\*\_\)_() ____(_,_,_,_,_),__(_,_,_,_) * _\(\_() \_\_\_\_(\_,\_,\_,\_,\_,\_),\_\_(\_,\_,\_,\_) \* \_\)_
()____(_,_) %>;___(\((m,i,au)[(\)(n,i,t)) _[_\(\_()\_\_\_\_(\_,\_,\_,\_)]%\_\_(\_,\_,\_,\_,\_)]);
\)_\((\_[\_\_(\_,\_ ,\_,\_ ,\_,\_,\_) + \_\_(\_,\_,\_,\_,\_,\_)]++){m(i,a,u) ( \_\)()) ;\(\_\) (_[_\(\_()
\_\_\_\_(\_,\_)]++)\)_\((\_[\_\)_()____(_,_,_)] \(\_\)_ _\(()) \)_(f,i)(_ [__(_,_,_,_,_,_,_) +
_\(\_()] != \_\_(\_)) \_\_\_(\_\)_()) ;{ m(i,a,u)(__$()); r(e,t) /* IOCCC 2014*/ %>
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.
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).
>toutes les versions du noyau encore supportées sont déjà corrigées,
" />
Après 9 ans … “déjà” corrigées …
???
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 ?
La fameuse intrication quantique et les marmottes, le papier alu tout ça…
Bonne soirée.
> 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
" />
Il peut y avoir une faille sur le serveur permettant d’exécuter un fichier préalablement uploadé.
> 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?
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….
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.
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.
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.
Ne te fatigue pas…
ben si le disque dur n’est pas encrypté, oui
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.
Pour y accéder par la gloire du Saint Esprit
En nombre absolu, Linux à bien plus de développeurs je pense.
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)
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).
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.
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 !
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 ?!
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 ?
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.
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.
L’orthographe est correcte ;)
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 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.
Les moyens ne sont pas que humain :)
en l’occurrence c’est ce dont je parlais :)