Une faille dans le kernel Linux vieille de 9 ans corrigée, mais déjà exploitée
Vieilles marmites
Le 21 octobre 2016 à 15h30
3 min
Logiciel
Logiciel
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.
Une faille dans le kernel Linux vieille de 9 ans corrigée, mais déjà exploitée
-
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)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 23/10/2016 à 19h31
ben si le disque dur n’est pas encrypté, oui
Le 23/10/2016 à 20h12
Le 23/10/2016 à 20h27
Le 23/10/2016 à 20h41
Le 23/10/2016 à 21h11
Le 23/10/2016 à 21h12
Le 23/10/2016 à 23h02
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.
Le 24/10/2016 à 04h19
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.
Le 24/10/2016 à 06h43
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.
Le 24/10/2016 à 07h05
Le 24/10/2016 à 07h15
Pour y accéder par la gloire du Saint Esprit
Le 24/10/2016 à 08h06
Le 24/10/2016 à 08h14
Le 24/10/2016 à 08h26
Le 24/10/2016 à 08h28
En nombre absolu, Linux à bien plus de développeurs je pense.
Le 24/10/2016 à 08h39
Le 22/10/2016 à 12h14
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.
Le 22/10/2016 à 13h54
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…
Le 22/10/2016 à 14h16
Le 22/10/2016 à 14h25
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).
Le 22/10/2016 à 15h50
Le 22/10/2016 à 15h52
Il te faut quoi pour que ça soie un mea culpa à tes yeux ??
Le 22/10/2016 à 16h13
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.
Le 22/10/2016 à 16h58
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?
Le 22/10/2016 à 17h01
Le 22/10/2016 à 17h26
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.
Le 22/10/2016 à 17h29
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 ?
Le 22/10/2016 à 18h06
Le 22/10/2016 à 18h38
Le 22/10/2016 à 18h42
Le 22/10/2016 à 18h43
Le 22/10/2016 à 18h47
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…
" />
Le 21/10/2016 à 15h38
Neuf ans, comme quoi, code visible ou pas, personne n’est à l’abri.
" />
Le 21/10/2016 à 15h39
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 !
Le 21/10/2016 à 15h40
J’entends les rageux de Cash Investigation se pointer, aïe aïe aïe
Le 21/10/2016 à 15h44
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
Le 21/10/2016 à 15h47
Alors monsieur Torvalds Linus on fait quoi ?
Le 21/10/2016 à 15h48
Le 21/10/2016 à 15h49
Le 21/10/2016 à 15h51
Le 21/10/2016 à 15h54
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 :)
Le 21/10/2016 à 17h00
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 !
Le 21/10/2016 à 17h01
Ça correspond peut être à la mise à jour de kernel que j’ai eue tout à l’heure (opensuse).
Le 21/10/2016 à 17h02
Have Fun :https://packetstormsecurity.com/files/139287/cowroot.c
Le 21/10/2016 à 17h05
HAPPEAU ????
Le 21/10/2016 à 17h13
Réponse de Linus Torvalds : C’est la faute de Nvidia ?
" />
‘dredi
Le 21/10/2016 à 17h20
Le 21/10/2016 à 17h27
Le 21/10/2016 à 17h36
Le 21/10/2016 à 17h59
Le 21/10/2016 à 18h08
Il répond avec calme et sénérité, comme d’hab
" />
Le 21/10/2016 à 18h47
So Fuck You nVidia
Le 21/10/2016 à 19h05
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.
Le 21/10/2016 à 19h14
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.
Le 21/10/2016 à 19h21
Le 21/10/2016 à 19h25
Le 21/10/2016 à 19h26
Le 23/10/2016 à 09h04
Le 23/10/2016 à 09h36
Le 23/10/2016 à 09h44
> 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 ?
Le 23/10/2016 à 10h12
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?
Le 23/10/2016 à 10h55
Le 23/10/2016 à 11h00
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 23/10/2016 à 12h10
Le 23/10/2016 à 12h46
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.
Le 23/10/2016 à 13h04
Le 23/10/2016 à 13h53
Le 23/10/2016 à 13h55
Le 23/10/2016 à 14h02
Le 23/10/2016 à 16h29
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.
Le 23/10/2016 à 17h38
Le 23/10/2016 à 18h58
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.
Le 23/10/2016 à 19h10
Ne te fatigue pas…
Le 21/10/2016 à 16h04
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:
Le 21/10/2016 à 16h05
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 
" />
" />
Le 21/10/2016 à 16h07
Le 21/10/2016 à 16h10
Le 21/10/2016 à 16h20
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.
Le 21/10/2016 à 16h24
Le 21/10/2016 à 16h29
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.
Le 21/10/2016 à 16h31
Le 21/10/2016 à 16h34
Le 21/10/2016 à 16h34
Les chats pourraient alors conquérir le monde !
Je ne sais pas si supprimer les humains est la solution du coup.
Le 21/10/2016 à 16h40
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 !
Le 21/10/2016 à 16h43
Le 21/10/2016 à 16h45
:grabpopcorn:
Le 21/10/2016 à 16h45
Le 21/10/2016 à 16h58
Le 21/10/2016 à 16h59
Le 24/10/2016 à 21h58
Le 25/10/2016 à 09h08
Le 25/10/2016 à 14h13
L’orthographe est correcte ;)
Le 25/10/2016 à 17h40
Le 26/10/2016 à 07h17
Si tu avais lu mon commentaire tu aurais vu que je parlais de Stretch et non de Jessie. Mais merci pour ton intervention.
Le 26/10/2016 à 16h27
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).
Le 26/10/2016 à 18h21
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.
Le 26/10/2016 à 19h54
Le 26/10/2016 à 21h43
Le 27/10/2016 à 07h43
Les moyens ne sont pas que humain :)
en l’occurrence c’est ce dont je parlais :)
Le 24/10/2016 à 08h40
Le 24/10/2016 à 08h43
Le 24/10/2016 à 09h47
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)
Le 24/10/2016 à 09h59
Le 24/10/2016 à 10h13
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?
Le 24/10/2016 à 10h23
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é.
Le 24/10/2016 à 11h49
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).
Le 24/10/2016 à 12h41
Le 24/10/2016 à 12h46
Le 24/10/2016 à 14h16
Le 24/10/2016 à 14h19
Le 24/10/2016 à 14h41
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.
Le 24/10/2016 à 15h40
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.
GitHubHum, ces anges de la vie privée s’appellent : Microsoft, Facebook et Google…
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 :
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 ?
Le 24/10/2016 à 16h21
Le 24/10/2016 à 16h23
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.
Le 24/10/2016 à 19h17
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.
Le 22/10/2016 à 02h40
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.
Le 22/10/2016 à 03h59
Son patch faisait sauter le level isolation ?
Le 22/10/2016 à 06h39
Le 22/10/2016 à 07h29
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
Le 22/10/2016 à 07h52
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….
Le 22/10/2016 à 08h13
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 ?
Le 22/10/2016 à 08h23
Le 22/10/2016 à 08h36
Le 22/10/2016 à 08h40
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)
Le 22/10/2016 à 10h17
Open Source = Open Threat
" />
Le 22/10/2016 à 10h37
Le 22/10/2016 à 10h39
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.
Le 22/10/2016 à 11h30
Le 22/10/2016 à 11h43
Comme quoi, JVachez était un visionnaire !
Le 22/10/2016 à 11h54
Le 22/10/2016 à 12h00
Le 21/10/2016 à 19h28
Le 21/10/2016 à 19h30
Le 21/10/2016 à 19h32
Le 21/10/2016 à 19h33
Le 21/10/2016 à 19h47
oh la la comme il m’a cassé mon délire du vendredi 
" />
Le 21/10/2016 à 20h27
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
Le 21/10/2016 à 20h38
Le 21/10/2016 à 20h41
Le 21/10/2016 à 21h20
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 !
Le 21/10/2016 à 21h30
Le 21/10/2016 à 21h31
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….
Le 21/10/2016 à 21h48
Ce n’est pas exploitable à distance. Il faut qu’une application infectée soit installée.
Mais c’est faisable.
Le 21/10/2016 à 21h54
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.
Le 21/10/2016 à 22h24
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.
Le 22/10/2016 à 01h01
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.
Le 22/10/2016 à 01h13
Le 22/10/2016 à 19h03
Le 22/10/2016 à 19h20
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 :)
Le 22/10/2016 à 19h24
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.
Le 22/10/2016 à 19h30
Le 22/10/2016 à 19h31
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).
Le 22/10/2016 à 20h17
>toutes les versions du noyau encore supportées sont déjà corrigées,
" />
Après 9 ans … “déjà” corrigées …
Le 22/10/2016 à 21h45
???
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 ?
Le 22/10/2016 à 23h11
Le 22/10/2016 à 23h46
La fameuse intrication quantique et les marmottes, le papier alu tout ça…
Bonne soirée.
Le 23/10/2016 à 01h36
Le 23/10/2016 à 08h06
Le 23/10/2016 à 08h27
Le 23/10/2016 à 08h28
> 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 ?
Le 23/10/2016 à 08h46
Je me demande si la faille est exploitable avec SELinux ? Vous savez, ce truc que tout le monde désactive
" />
Le 23/10/2016 à 08h54
Le 23/10/2016 à 09h03
Il peut y avoir une faille sur le serveur permettant d’exécuter un fichier préalablement uploadé.