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é dansLogiciel

21/10/2016
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
Avatar de l'auteur

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Une petite fille en train d'apprendre à programmer et hacker logiciels et appareils électroniques

Un roman graphique explique les logiciels libres aux enfants

Hacking 4 freedom

11:24 SoftSociété 17
Nouveautés pour Messenger

Meta lance (enfin) le chiffrement de bout en bout de Messenger, entre autres

ME2EEssenger

08:43 Socials 3

Windows en 2024 : beaucoup d’IA, mais pas forcément un « 12 »

Technique contre marketing

17:36 Soft 15

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

Une petite fille en train d'apprendre à programmer et hacker logiciels et appareils électroniques

Un roman graphique explique les logiciels libres aux enfants

SoftSociété 17
Nouveautés pour Messenger

Meta lance (enfin) le chiffrement de bout en bout de Messenger, entre autres

Socials 3

#LeBrief : cloud européen, OSIRIS-REx a frôlée la catastrophe, CPU AMD Ryzen 8040

Windows en 2024 : beaucoup d’IA, mais pas forcément un « 12 »

Soft 15
Einstein avec des qubits en arrière plan

Informatique quantique, qubits : avez-vous les bases ?

HardScience 8
Notifications iPhone

Surveillance des notifications : un sénateur américain demande la fin du secret

DroitSécu 14

En ligne, les promos foireuses restent d’actualité

DroitWeb 18

#LeBrief : modalité des amendes RGPD, cyberattaque agricole, hallucinations d’Amazon Q, 25 ans d’ISS

Logo Twitch

Citant des « coûts prohibitifs », Twitch quitte la Corée du Sud

ÉcoWeb 29
Formation aux cryptomonnaies par Binance à Pôle Emploi

Binance fait son marketing pendant des formations sur la blockchain destinées aux chômeurs

Éco 10
Consommation électrique du CERN

L’empreinte écologique CERN en 2022 : 1 215 GWh, 184 173 teqCO₂, 3 234 Ml…

Science 6
station électrique pour voitures

Voitures électriques : dans la jungle, terrible jungle, des bornes de recharge publiques

Société 74

#LeBrief : intelligence artificielle à tous les étages, fichier biométrique EURODAC

KDE Plasma 6

KDE Plasma 6 a sa première bêta, le tour des nouveautés

Soft 13
Un homme noir regarde la caméra. Sur son visage, des traits blancs suggèrent un traitement algorithmique.

AI Act et reconnaissance faciale : la France interpelée par 45 eurodéputés

DroitSociété 4
Api

La CNIL préconise l’utilisation des API pour le partage de données personnelles entre organismes

SécuSociété 3
Fouet de l’Arcep avec de la fibre

Orange sanctionnée sur la fibre : l’argumentaire de l’opérateur démonté par l’Arcep

DroitWeb 22
Bombes

Israël – Hamas : comment l’IA intensifie les attaques contre Gaza

IA 22

#LeBrief : bande-annonce GTA VI, guerre électronique, Spotify licencie massivement

Poing Dev

Le poing Dev – Round 7

Next 101
Logo de Gaia-X sour la forme d’un arbre, avec la légende : infrastructure de données en forme de réseau

Gaia-X « vit toujours » et « arrive à des étapes très concrètes »

WebSécu 6

Trois consoles portables en quelques semaines

Hard 37
Une tasse estampillée "Keep calm and carry on teaching"

Cyberrésilience : les compromis (provisoires) du trilogue européen

DroitSécu 3

#LeBrief : fuite de tests ADN 23andMe, le milliard pour Android Messages, il y a 30 ans Hubble voyait clair

#Flock a sa propre vision de l’inclusion

Flock 25
Un Sébastien transformé en lapin par Flock pour imiter le Quoi de neuf Docteur des Looney Tunes

Quoi de neuf à la rédac’ #10 : nous contacter et résumé de la semaine

44
Fairphone 5 démonté par iFixit

Sans surprise, le Fairphone 5 obtient 10/10 chez iFixit

Hard 2

WhatsApp vocaux à vue/écoute unique

WhatsApp permet d’envoyer des vocaux à écoute unique

Soft 9

Logo de Google sur un ordinateur portable

Google propose un correctif aux disparitions mystérieuses sur Drive

Soft 21

Puce AMD Instinct

IA : AMD annonce la disponibilité des accélérateurs Instinct MI300A et MI300X

Hard 0

Un œil symbolisant l'Union européenne, et les dissensions et problèmes afférents

Cloud : 1,2 milliard d’euros pour un Projet important d’intérêt européen commun

Web 11

Sonde OSIRIS-REx de la NASA lors du retour de la capsule des échantillons sur Terre

Échantillons d’OSIRIS-REx : la NASA a frôlé la catastrophe

Science 11

CPU AMD Ryzen avec NPU pour l’IA

Ryzen 8040 : AMD lance de nouveaux CPU mobiles (Zen 4, RDNA 3, NPU)

Hard 2

Commentaires (163)


after_burner
Le 21/10/2016 à 15h38

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





<img data-src=" />


bord
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 !


jackjack2
Le 21/10/2016 à 15h40

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


maxoux
Le 21/10/2016 à 15h44

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=" />


sniperdc
Le 21/10/2016 à 15h47

Alors monsieur Torvalds Linus on fait quoi ?


FRANCKYIV
Le 21/10/2016 à 15h48






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=" />



fred42 Abonné
Le 21/10/2016 à 15h49






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 !



bord
Le 21/10/2016 à 15h51






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 ^^ )



millcaj
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 :)


Network
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.&nbsp;

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


anonyme_d5bf0b9f87fd15affa58563db3b0ac5d
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&nbsp;<img data-src=" /><img data-src=" />


neves
Le 21/10/2016 à 16h07






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=" />



jackjack2
Le 21/10/2016 à 16h10






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



ArchangeBlandin Abonné
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.


Mihashi Abonné
Le 21/10/2016 à 16h24

<img data-src=" />


thomgamer
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.


after_burner
Le 21/10/2016 à 16h31






jackjack2 a écrit :

Bim



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



Haemy
Le 21/10/2016 à 16h34






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=" />



ArchangeBlandin Abonné
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.


thomgamer
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 !


bord
Le 21/10/2016 à 16h43






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.



dylem29 Abonné
Le 21/10/2016 à 16h45

:grabpopcorn:


calarfe
Le 21/10/2016 à 16h45






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…..



catseye
Le 21/10/2016 à 16h58






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=" />



Samsara
Le 21/10/2016 à 16h59

<img data-src=" />


Commentaire_supprime
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 !


Winderly Abonné
Le 21/10/2016 à 17h01

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


Anonymous Coward
Le 21/10/2016 à 17h02
Yseader Abonné
Le 21/10/2016 à 17h05

HAPPEAU ????


tpeg5stan Abonné
Le 21/10/2016 à 17h13

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

<img data-src=" />
‘dredi


ragoutoutou Abonné
Le 21/10/2016 à 17h20






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…)



zefling Abonné
Le 21/10/2016 à 17h27






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.



anonyme_5308cee4763677866e1421efa4474f79
Le 21/10/2016 à 17h36






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.



after_burner
Le 21/10/2016 à 17h59






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=" />



Jarodd Abonné
Le 21/10/2016 à 18h08
sniperdc
Le 21/10/2016 à 18h47

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

*So Fuck You nVidia*


Obidoub
Le 21/10/2016 à 19h05

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.


js2082
Le 21/10/2016 à 19h14

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.


karnox
Le 21/10/2016 à 19h21






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 ?



Ricard
Le 21/10/2016 à 19h25






bord a écrit :

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


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



Ricard
Le 21/10/2016 à 19h26






sniperdc a écrit :

Alors monsieur Torvalds Linus on fait quoi ?


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



Ricard
Le 21/10/2016 à 19h28






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=" />



Ricard
Le 21/10/2016 à 19h30






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=" />



Ricard
Le 21/10/2016 à 19h32






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=" />



Ricard
Le 21/10/2016 à 19h33






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=" />



sniperdc
Le 21/10/2016 à 19h47

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


teddyalbina Abonné
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


thomgamer
Le 21/10/2016 à 20h38






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=" />



jb07 Abonné
Le 21/10/2016 à 20h41

<img data-src=" />


Timothée
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 !


Commentaire_supprime
Le 21/10/2016 à 21h30






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 !



scarmax Abonné
Le 21/10/2016 à 21h31

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;


psn00ps Abonné
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.


v6relou
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.


Kerwan Abonné
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.


Mr.Nox Abonné
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.


sr17
Le 22/10/2016 à 01h13






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.



Aloyse57
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.


Z-os Abonné
Le 22/10/2016 à 03h59

Son patch faisait sauter le level isolation ?


Haemy
Le 22/10/2016 à 06h39






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.



kypd
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 <img data-src=" />


Axka
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….


popo76
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&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 ?


Konrad
Le 22/10/2016 à 08h23






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.



Konrad
Le 22/10/2016 à 08h36






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…



ragoutoutou Abonné
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&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)


127.0.0.1
Le 22/10/2016 à 10h17

Open Source = Open Threat

<img data-src=" />


Ricard
Le 22/10/2016 à 10h37






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=" />



tazvld Abonné
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.


127.0.0.1
Le 22/10/2016 à 11h30






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.



Zergy
Le 22/10/2016 à 11h43

Comme quoi, JVachez était un visionnaire !


ignace72
Le 22/10/2016 à 11h54






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



ignace72
Le 22/10/2016 à 12h00






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.



dieudivin
Le 22/10/2016 à 12h14

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.


Citan666 Abonné
Le 22/10/2016 à 13h54

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;


Konrad
Le 22/10/2016 à 14h16






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.



Quiproquo Abonné
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).


vampire7
Le 22/10/2016 à 15h50






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…



psn00ps Abonné
Le 22/10/2016 à 15h52

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”).



teddyalbina Abonné
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.


étienne
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?


ignace72
Le 22/10/2016 à 17h01






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]



127.0.0.1
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.


morpheus_
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 ?


127.0.0.1
Le 22/10/2016 à 18h06






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.



Konrad
Le 22/10/2016 à 18h38






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 ».



Konrad
Le 22/10/2016 à 18h42






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…



morpheus_
Le 22/10/2016 à 18h43






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.



anonyme_fe2dc0916364b246b7518dab0376e442
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… <img data-src=" />


morpheus_
Le 22/10/2016 à 19h03






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 ?



morpheus_
Le 22/10/2016 à 19h20

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 :)


Quiproquo Abonné
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.


RaphAstronome Abonné
Le 22/10/2016 à 19h30






é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”.



Quiproquo Abonné
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).


FRANCKYIV
Le 22/10/2016 à 20h17

&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=" />


morpheus_
Le 22/10/2016 à 21h45

???
&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 ?


127.0.0.1
Le 22/10/2016 à 23h11






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.



morpheus_
Le 22/10/2016 à 23h46

La fameuse intrication quantique et les marmottes, le papier alu tout ça…
Bonne soirée.


cedricpc Abonné
Le 23/10/2016 à 01h36






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=" />



Spydeus
Le 23/10/2016 à 08h06






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 !



sans sucre
Le 23/10/2016 à 08h27

<img data-src=" />





sniperdc a écrit :

Alors monsieur Torvalds Linus on fait quoi ?


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



doom_Oo7
Le 23/10/2016 à 08h28

&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 ?


Obidoub
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 <img data-src=" />


fmo Abonné
Le 23/10/2016 à 08h54






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…



Quiproquo Abonné
Le 23/10/2016 à 09h03

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


cedricpc Abonné
Le 23/10/2016 à 09h04






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=" />



Vachalay
Le 23/10/2016 à 09h36






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)…



127.0.0.1
Le 23/10/2016 à 09h44

&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 ?


trekker92
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?


after_burner
Le 23/10/2016 à 10h55






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.



anonyme_17187f2fe30034ef77b37a104608a3ce
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….


trekker92
Le 23/10/2016 à 12h10






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.



js2082
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.


vampire7
Le 23/10/2016 à 13h04






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.



Konrad
Le 23/10/2016 à 13h53






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).



Konrad
Le 23/10/2016 à 13h55






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à…



after_burner
Le 23/10/2016 à 14h02






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à.



dieudivin
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.


trekker92
Le 23/10/2016 à 17h38






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.



Zelfir
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.
&nbsp;


Quiproquo Abonné
Le 23/10/2016 à 19h10
doom_Oo7
Le 23/10/2016 à 19h31

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


sr17
Le 23/10/2016 à 20h12






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…



Konrad
Le 23/10/2016 à 20h27






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…



Patch Abonné
Le 23/10/2016 à 20h41






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=" />



sr17
Le 23/10/2016 à 21h11






-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.




sr17
Le 23/10/2016 à 21h12






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=" />



CaptainDangeax
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.


Cashiderme
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.


wanou2 Abonné
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.


Patch Abonné
Le 24/10/2016 à 07h05






sr17 a écrit :

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

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



levhieu
Le 24/10/2016 à 07h15

Pour y accéder par la gloire du Saint Esprit


anonyme_95bde7ad91b4483068f10094cf1c28ca
Le 24/10/2016 à 08h06






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.




Soriatane Abonné
Le 24/10/2016 à 08h14






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.



uzak
Le 24/10/2016 à 08h26






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 ?



Network
Le 24/10/2016 à 08h28

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


vampire7
Le 24/10/2016 à 08h39






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…



CaptainDangeax
Le 24/10/2016 à 08h40






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 ?



seb2411
Le 24/10/2016 à 08h43






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.



JCDentonMale
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)


Pr. Thibault
Le 24/10/2016 à 09h59






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.



gazgaz78
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?


Soriatane Abonné
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é.


morpheus_
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).


Cashiderme
Le 24/10/2016 à 12h41






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.



Ayak973
Le 24/10/2016 à 12h46






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



WereWindle
Le 24/10/2016 à 14h16






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=" /> )



Konrad
Le 24/10/2016 à 14h19






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.



j-c_32
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.
&nbsp;


Shyfer
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.
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 ?


Konrad
Le 24/10/2016 à 16h21






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-c_32
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.
&nbsp;


Quiproquo Abonné
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.


sr17
Le 24/10/2016 à 21h58






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.



CaptainDangeax
Le 25/10/2016 à 09h08






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 .



psn00ps Abonné
Le 25/10/2016 à 14h13

L’orthographe est correcte ;)


CoooolRaoul
Le 25/10/2016 à 17h40






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?



JCDentonMale
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.


Quiproquo Abonné
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).


teddyalbina Abonné
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&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.


Konrad
Le 26/10/2016 à 19h54






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.



sr17
Le 26/10/2016 à 21h43






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.



karnox
Le 27/10/2016 à 07h43

Les moyens ne sont pas que humain :)
en l’occurrence c’est ce dont je parlais :)