Un article intéressant sur Futura-Sciences explique comment on pourrait pirater un ordinateur avec de l'ADN : certains algorithmes sont conçus pour analyser des brins d'ADN ne contenant qu'un nombre maximum de paires (ACTG). En fournissant à ces algos un brin d'ADN plus long que prévu, on peut provoquer un dépassement de mémoire et introduire du code malveillant dans le surplus d'ADN. Bref un cas typique d'attaque par buffer overflow.
Là où l'article est carrément moins intéressant c'est qu'ils sous-entendent que ça serait la faute de l'open source et des langages utilisés :
L'une des raisons pour expliquer ces lacunes graves est qu'il s'agit de programmes open source écrits avec les langages de programmation C et C++ qui sont connus pour leurs failles de sécurité.
Je ne suis ni biologiste, ni dev C++ mais il me semble qu'on sait depuis bien longtemps se prémunir de ces attaques et puis bon, un mauvais code, libre ou pas, est un mauvais code.
# Oui mais non
Posté par lockidor . Évalué à 9. Dernière modification le 12 août 2017 à 17:12.
S'ils font bien référence au papier que j'ai vu passer récemment (edit : oui, c'est bien celui-ci), des chercheurs ont pris un outil opensource, ont volontairement inséré une faille de sécurité dedans, et montré qu'effectivement, leur ADN manipulé déclenchait leur faille artificielle.
En même temps, ce n'est pas totalement faux. Les gens ne se sont pas amusés à sortir Rust/Swift/Go/… juste pour passer le temps.
[^] # Re: Oui mais non
Posté par pralines . Évalué à 7.
oui, ils se sont vraiment "simplifié" le travail
que les scientifiques qui écrivent ces logiciels analyseurs de génome ne se soucient pas de la sécurité ne me choque pas, ça n'est pas leur métier,
en revanche, ça devrait être celui des sociétés qui reprennent gratuitement ce code libre pour l'intégrer aux machines qu'ils vendent, mais faut pas rêver, quand on voit que des matériels médicaux vitaux (pacemaker, pompes à insuline,…) sont vulnérables à des attaques informatiques
je suppose qu'il faut attendre les premiers morts ou accidents graves et les procès qui vont automatiquement avec aux USA pour voir changer les pratiques, ça sera probablement bien plus efficace qu'un article dans une revue scientifique
Envoyé depuis mon Archlinux
[^] # Re: Oui mais non
Posté par totof2000 . Évalué à 4.
Euh … ben moi ça me choque quand même. Certes onb ne peut pas forcément leur demander de faire de l'hyper sécurisé, mais ils pourraient au moins faire un minimum d'efforts.
Celà dit, dire que le C ou le C++ sont sont connus pour leurs failles de sécurité, ça n'a pas de sens : les langages en eux-même n'ont pas de faille de sécurité (sinon je m'inquièterais pour mon système, dont les couches basses sont écrites en C). Il serait plus correct d'écrire qu'il est plus difficile d'écrirte du code sûr en C ou en C++ qu'avec d'autres langages.
[^] # Re: Oui mais non
Posté par Marotte ⛧ . Évalué à 3.
Mais leurs implémentations si (potentiellement).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -7. Dernière modification le 13 août 2017 à 04:06.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Oui mais non
Posté par Marotte ⛧ . Évalué à 5.
Je faisais évidemment référence aux compilateurs/interpréteurs, qui sont bien, si je ne m’abuse, des mises en œuvre des langages en eux-mêmes.
L’exception que tu cites ne fait que confirmer la règle que j’énonçais ! ;)
[^] # Re: Oui mais non
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 1.
Le language C a supprimé la fonction gets() dans sa version 2011, pour des raisons de sécurité. Donc oui, des failles dans un langage, ça existe.
[^] # Re: Oui mais non
Posté par Colin Pitrat (site web personnel) . Évalué à 10.
La fonction gets c'est pas un problème avec le langage, c'est une fonction d'une librairie (certes standardisée et fortement liée).
Un exemple de faille dans le langage, c'est par exemple quand on peut forcer java à avoir une référence invalide alors que le langage a été conçu pour rendre celà impossible (https://dev.to/rosstate/java-is-unsound-the-industry-perspective)
Ce genre de problème ne risque pas d'exister en C puisque le langage est très simple et n'introduit pas d'abstraction cherchant à limiter ce qui peut être fait avec.
[^] # Re: Oui mais non
Posté par StyMaar . Évalué à 2.
En réalité, la raison pour laquelle ce genre de «bug» ne peut pas arriver en C, ce n'est pas tant que le langage est «simple», mais parce que sa spécification est laxiste : elle stipule explicitement que les développeurs de compilateurs peuvent faire absolument ce qu'ils veulent dès qu'un cas tordu se présente : ce sont les Undefined Behavior. Les compilateurs ont le droit de supposer que ces cas là n'arrivent jamais, et si jamais le programmeur provoque l'un de ces cas, alors le compilateur est libre de faire ce qu'il veut, le développeur n'avait qu'à pas être bête.
Dans ces conditions, c'est plus effectivement facile pour un compilateur de respecter la spec' !
[^] # Re: Oui mais non
Posté par Renault (site web personnel) . Évalué à 3.
C'est un des but et de l'intérêt du C aussi (ce n'est pas sans inconvénient comme politique, mais ça a des avantages).
Cela peut permettre pas mal d'optimisations, cela simplifie grandement l'écriture d'un nouveau compilateur ou la gestion d'une nouvelle architecture matérielle. Pas pour rien que le C est le langage disponible sur le plus d'architectures au monde, car sa norme est légère et souple.
Mais oui le revers est en effet que de nombreuses situations courantes ne sont pas vraiment définies ce qui ouvre le droit à des bogues selon l'implémentation du compilateur et l'architecture donnée si jamais le développeur n'a pas fait gaffe.
On ne peut pas tout avoir.
[^] # Re: Oui mais non
Posté par kantien . Évalué à 3.
Ce n'est pas ce que dit l'article cité dans le commentaire auquel tu réponds : le problème se trouve dans la spécification du système de type de Java et non dans un compilateur donné. Le système de type de Java est unsound et cela d'après sa spécification.
L'exemple est celui-ci :
l'auteur de l'article précise bien qu'il y a des compilateurs qui refuseront de compiler en considérant qu'il y a une erreur de typage dans le code, mais alors le bug est dans le compilateur qui ne respecte pas la spécification du langage.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Oui mais non
Posté par lockidor . Évalué à 4.
D'accord, et tu paies les financement pour que ce soit bien fait ?
Ensuite, comme je le disais plus haut, le code originel était secure, c'est les zozos de l'article qui ont rajoute une faille.
[^] # Re: Oui mais non
Posté par totof2000 . Évalué à 0.
Euh … il y a un certain nombre de règles de base à respecter quand on développe du code, quel que soit notre niveau.
Si tu veux refaire l'installation électrique de ton domicile (pour économiser), tu es contraint par un certain nombre de règles de sécurité pour ne pas te mettre, toi et tes voisins, en danger. Il te faut donc te renseigner sur ces règles/contraintes pour les respecter. Pour le code c'est la même chose (à un détail près : le respect de règles de codages sûres n'est pas imposé par la loi). Il est donc normal que les développeurs, même occasionnels, soit un minimum au courant des règles à respecter pour développer un programme qui ne cède pas aux attaques de base.
OK, donc les développeurs "originaux" ont à priori rien à se reprocher, mais certains développeurs "occasionnels" ont un peu tendance à ne pas se soucier de la sécurité de leur code, ce qui est un tort (le fait de ne pas être un pro du développement, ou vouloir économiser en abaissant la sécurité ne me paraissent pas de bonnes excuses).
[^] # Re: Oui mais non
Posté par lockidor . Évalué à 1.
En même temps que tu encadres tes stagiaires/doc/postdoc, rédiges un dossier de financement, écrit un article ou deux, te bats avec l'administration pour des questions de fonctionnement et essaies de garder le peu temps qu'il te reste pour ta recherche en elle-même. Et la sécurité d'un code qui n'est jamais censé être soumis à des données compromises (on parle de séquençage ADN là, pas de webservice) et aux conséquences quasi-inexistantes (même si quelqu'un parvient à tripatouiller l'ADN des bestioles qui seront séquencées, il se passe quoi : la machine – non connectée au réseau – va planter ? La belle affaire…) ne sera jamais budgétée ; on a déjà suffisamment de mal à avoir de l'argent pour le coeur des projets.
La prochaine fois, tu vas reprocher aux ingénieurs des Mulberries de ne pas avoir respecté les règles environnementales ? Il y a une histoire de priorité et de budget financier et temporel fini.
Si en plus tu crois que la sécurité ça se limite à suivre quelques règles, tu ne dois pas – sauf ton respect – avoir jamais fait de vraie sécurité. C'est un métier à part entière pour une bonne raison. Et quand tu vois le nombre colossal de failles de sécurité que l'on peut trouver dans des projets très sérieux comme Linux, OpenSSL ou OS X, tu te doutes bien qu'un gusse dont le coeur de métier est la bioinfo n'aura ni le temps, ni les compétences pour mieux faire.
[^] # Re: Oui mais non
Posté par totof2000 . Évalué à 1.
T'es en mode Zenitram la ? Ou ai-je écrit ça ? Nulle part. Moi aussi je peux faire pareil : tu cherches un pretexte bidon justifier tes développements pourris ? Je n'ai jamais écrit que la sécurité se limite au respect de quelques règles. Par contre je dis que la sécurité commence par le respect de quelques règles de base. Tu vas laisser la porte de ton domicile ouverte sous prétexte qu'une porte hyper sécurisée et blindée coute trop cher (ou toute excuse que tu pourras mettre ici) ?
Ben si t'es pas fichu de respecter quelques pratiques de base dans le langage dans lequel tu développes, ben ne code pas. L'une des règles de base en dev est de ne pas faire confiance aux données qui viennent de l'extérieur, et de s'assurer que celles-ci ne pourront pas compromettre ton système (ce sera fait différemment en fonction de ce que tu développes et de ton environnement). Et le pretexte du code qui n'est jamais censé être soumis a des données compromises ne tient pas : ton code peut être réutilisé ailleurs par quelqu'un d'autre qui pourra supposer que celui-ci est clean, dans un environnement ou ça sera plus problématique.
[^] # Re: Oui mais non
Posté par freem . Évalué à 6.
Hum… laissez-moi réfléchir 2 secondes… C et C++ ne sont pas sécurisés. Ok. C'est vrai, on peut faire de la merde avec, force est de le reconnaître.
Mais par contre, pourquoi toujours mettre le C et le C++ dans le même panier? Pour rappel, en C++ il est possible de gérer la mémoire (et de manière générale les ressources, en fait) automatiquement. La seule raison d'appeler directement delete(), c'est quand on écrit du code pour gérer les ressources, sinon on a le choix, entre vector, list,
auto_ptr (c++98, c'est trop récent je suppose)unique_ptr (c++11), …La ou le C++ n'offre à ma connaissance aucun outil en standard, c'est dans le traitement du dépassement de capacité des entiers, utilisés parfois pour accéder aux éléments d'un tableau (c'est bien le cas qui nous intéresse ici, non?).
D'un autre côté, quand on utilise des tableaux alloués dynamiquement (et statiquement aussi, depuis 2011), si on fait les choses dans la façon de faire recommandée du langage, on utilise vector, qui offre à mon humble avis tout ce qu'il faut pour éviter d'accéder à des éléments hors limite.
Bref, ok, le C n'offre aucun moyen simple de coder en sécurité de façon standard (quoique, ça à peut-être évolué, ça fait longtemps que je ne suis plus le langage C), mais pour le C++, si on utilise les outils du C++ et pas ceux du C, on peut coder simplement en évitant les accès mémoire foireux, le tout avec une performance globalement identique au C (parfois un peu moins, parfois un peu plus, notamment std::sort vs qsort), réputé le plus performant des langages portables.
[^] # Re: Oui mais non
Posté par fearan . Évalué à 3.
Tu peux ajouter la possibilité depuis C++11 d'exécuter du code en sortie de bloc quel que soit le chemin pris par le code (throw, return, exit, break, goto…), à l'exception de _exit et la réception d'un signal, qui sont des cas très particulier.
Cela permet, par exemple, de gérer des ressources externes venant de bibliothèques C de manière 'propre'.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Oui mais non
Posté par freem . Évalué à 3. Dernière modification le 14 août 2017 à 15:01.
Je ne vois pas ce que tu veux dire la? Je suis preneur d'un p'tit snippet, si tu peux :p
Hum… perso dans ces moments la je passe par par std::unique_ptr… sauf pour les IDs, pour lesquels je me suis bricolé un équivalent, mais il faudrait pour être bien que j'implémente une version tableaux… ça serait bien pratique pour des libérer d'un bloc un jeu d'ID OpenGL par exemple (ou de descripteurs de fichiers, ou… bref).
[^] # Re: Oui mais non
Posté par fearan . Évalué à 3.
Oui, généralement c'est le cas, mais parfois c'est un peu plus que juste un free, mais c'est assez rare
Un quick & dirty, (détournement d'outils standard, à éviter) :
Sinon tu peux facilement faire un objet qui prends une fonction en paramètre et l'exécute en sortie de bloc (destructeur), par contre ne pas oublier que les exceptions dans les destructeurs sont généralement à éviter, il y a quelques exemples ici, avec en prime des version pile, permettant d'enchainer les actions ;)
https://stackoverflow.com/questions/10270328/the-simplest-and-neatest-c11-scopeguard
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Oui mais non
Posté par freem . Évalué à 3.
Mais ce n'est pas un problème: avec unique_ptr tu peux spécifier la fonction à utiliser pour libérer la ressource.
Bon, ok, ça transforme un pointeur léger (même taille qu'un pointeur brut) en pointeur lourd (stockage de l'@ du destructeur en plus de l'@ de la donnée) et c'est pénible à utiliser, mais ça fonctionne.
Ceci dit, je regrette très fortement que unique_ptr soit si pénible à utiliser avec des pointeurs C et ajoute un overhead alors qu'il aurait été possible de l'éviter (en passant le nom du destructeur en Template, et non en paramètre du constructeur: ça aurait évité d'utiliser un pointeur supplémentaire inutile et ça aurait rendu la chose bien plus simple à utiliser!).
Hum… je vois pas la valeur ajoutée par rapport à:
Bon, ça compile probablement pas, mais l'idée est là.
Les bouts de code sur lesquels tu pointes me semblent bien complexes pour… je ne sais pas quoi, je dirai rien mais j'imagine qu'il y a quelque chose que je n'ai pas tilté :D
[^] # Re: Oui mais non
Posté par fearan . Évalué à 3.
Oui, parce qu'ils gèrent le fait d'annuler l'exécution en fin de bloc :P.
Ensuite on est pas obligé de se limiter à la libération de pointeur, parfois c'est juste un popcontext, ou si tu fais du SAX (xml), un endElement, ça peut être des appends sur un logger, la construction du retour de ta fonction, ça peut être un nettoyage de répertoires temporaires, un message au client distant que tu passes dans un autre état…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Oui mais non
Posté par freem . Évalué à 2.
Je vois, je regarderai plus en details donc (pas simple sur tel).
Concretement, ce que le cpp11 apporte, c'est "juste" le confort des lambda ou il y a autre chose?
[^] # Re: Oui mais non
Posté par fearan . Évalué à 3.
Dans ce cas là oui; la possibilité de référencer les variable locale dans la lambda, associé au std::function (c++11) (ou même auto), donne une simplicité d'écriture qu'on avait pas avant.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Oui mais non
Posté par freem . Évalué à 3.
Merci.
Je parlais bien entendu du cas du scope guard, je sais bien que le C++11 apporte énormément en terme de perf et de maintenabilité :) (move semantic, range for, smart pointers plus fiables, opérations atomiques et cætera, la liste est longue, c'est pas une version majeure pour rien celle-la)
# Déformation journalistique
Posté par gouttegd . Évalué à 10.
Il faut bien préciser que c’est le journaleux de Futura-Sciences qui fait ce sous-entendu, qui n’apparaît nulle part dans l’article original. Les auteurs ont étudié des programmes open source parce que ① par définition on peut étudier leur code source (et donc trouver des failles potentielles sans recourir au fuzzing ou autres techniques assimilées) et ② la plupart des programmes d’analyse de séquences sont de toutes façons open source. Mais à aucun moment le caractère open source de ces programmes n’est avancé comme une cause de leurs vulnérabilités, contrairement à ce que prétend l’article de Futura-Sciences…
Il est aussi intéressant de noter que la « preuve de concept » rapportée a été établie avec une vulnérabilité délibérément introduite dans un logiciel open source par les auteurs de l’article (pourquoi se fatiguer à chercher une vraie vulnérabilité exploitable quand on peut la créer soi-même).
[^] # Re: Déformation journalistique
Posté par Framasky (site web personnel) . Évalué à 6.
Pour établir un proof of concept et montrer que des logiciels peuvent être attaqués via l'ADN qu'ils analysent.
Je trouve que l'idée n'est pas mauvaise : ils n'ont apparemment fait que baisser la taille de la mémoire tampon du logiciel, sans doute parce que c'était plus simple que de fabriquer un brin d'ADN possédant suffisamment de paires de bases pour dépasser la taille de la mémoire tampon. Le jour où il sera simple de fabriquer un tel brin d'ADN, leur proof of concept aura, j'espère, démontré l'importance d'avoir un mécanisme bloquant une telle faille et que les logiciels seront déjà protégés.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Déformation journalistique
Posté par pralines . Évalué à 3.
Envoyé depuis mon Archlinux
[^] # Re: Déformation journalistique
Posté par Framasky (site web personnel) . Évalué à 5.
J'avoue que je n'ai pas été revoir l'article originel. Et quand bien même : ça montre bien qu'il y a des points à surveiller quand on écrit un logiciel d'analyse ADN, et donc qu'il va falloir se préoccuper de la sécurité dès maintenant. Même si ces points à surveiller sont des choses qui nous paraissent aller de soi, va savoir ce que quelqu'un qui n'a rien à foutre de la sécurité peut faire dans l'industrie. Pensons à l'IoT et ses failles dans tous les sens, ou le coup des pacemakers paramétrables sans authentification d'aucune sorte, juste parce que la sécurité ne fait pas partie des questions que les fabricants se posent.
J'espère que ce PoC fera l'objet d'une prise de conscience dans le domaine de l'analyse d'ADN (et j'ose même pas avoir le moindre espoir pour le reste de l'industrie de l'analyse biologique).
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Déformation journalistique
Posté par Sufflope (site web personnel) . Évalué à 10.
C'est vraiment pour faire du putaclic leur histoire. Remplace ADN par autre chose de bien moins sensationnaliste et effectivement si tu codes en dur une taille, que tu fais aucune vérif. des données, que tu désactives les protections OS/matérielles… oui à la fin ça va sûrement réussir à planter, bravo bel exploit. Proof of concept de rien du tout.
[^] # Re: Déformation journalistique
Posté par xcomcmdr . Évalué à 4.
Proof of Idiotic Concept.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Déformation journalistique
Posté par ylsul . Évalué à 9.
Il peut s'agir d'une tentative de mettre en évidence les dangers d'une attention insuffisante accordée à la sécurité dans un domaine qui n'a pas l'habitude de se pencher sur cette question, comme quelqu'un le relève dans un autre commentaire.
Pour la désactivation des sécurités du système d'exploitation, c'est un peu normal : s'il existe plusieurs couches de sécurité, il est difficile de montrer une faille dans l'une d'elle tant que les autres bouchent le trou. Ce qui n'empêche pas qu'il soit nécessaire de considérer la faille. La défense en profondeur repose sur des défenses multiples mais on s'attache à ce que chacune essaie au mieux de faire son travail, donc pour la tester on ignore ce que font les autres. Si les autres couches rattrapent le coup dans la vraie vie un jour où un problème survient, tant mieux.
Donc putaclic pour Futurama peut-être ; la publication d'origine c'est moins évident s'il s'agit de sensibiliser le secteur à certaines bonnes pratiques ("vérifiez vos données en entrée" :) ).
[^] # Re: Déformation journalistique
Posté par littlebreizhman . Évalué à 4. Dernière modification le 12 août 2017 à 21:44.
Le problème n'est pas, à mon avis,la synthèse de fragments d'ADN long mais leur séquençage sans erreur, plus la séquence est longue, plus le nombre d'erreur augment et le "code" contenu sera altéré et corrompu. Les méthodes de séquençage courantes (tyep Illumina, la techno utilisés dans le séquençage de l'article sont dont faites pour des séquences assez courtes.
Les méthodes pour séquencer de longues séquences génèrent des séquences très bruitées corrigeables mais rarement à 100%.
Les buffers des logiciels expertisés et celui qu'ils ont trafiqué sont probablement petits car ils sont fait pour gérer des reads courtes. Cela ne minimise en rien le problème potentiel même si c'est se donner bien du mal pour lancer une attaque.
Et si les séquenceurs s'améliore, les tailles maximen de séquence augmenteront.
D'un coté expérimental, il faut injecter cet ADN malveillant dans un ou des échantillons candidats au séquençage quasiment au moment de leur dépôts dans le séquenceur (toute intégration avant risque de voir la séquence maltraité par toutes les étapes pré-séquençages, qu'il bosse suffisamment proprement pour ne pas altérer suffisamment la séquence malicieuse, qu'elle soit démultiplexé (si l'index accolé à cette séquence n'est pas prévu dans l'analyse "infectée", il ne sera pas cherché et la séquence sera mise de coté [1]) et qu’ensuite elle soit lue par un des logiciels susceptibles d'être impactés.
L'article de Futura tech est approximatif : FASTQ est un format de données de séquençage pas un logiciel.
L'article original est plutôt intéressant à lire comme poc - il fallait y penser. Par contre, le logiciel (un programme optimisé pour la compressions des fichiers FASTQ) altéré est sûrement peu utilisé, les logiciels assurant le démultiplexage des séquences produisent le plus souvent des fichiers au format fastq compressés (gz ou bz2) et ils sont souvent utilisés tels quels.
Les logiciels d'optimisations de compression des fichiers de séquences sont abordés lorsque l'on veut faire du stockage optimisé pour le long terme, les logiciels de manipulations et d'analyse de séquence s'attendent en général à un format gz ou bz2 ou sans compression.
Les compressions optimisées devant être converties vers ces "standards" pour être à nouveau utilisables.
[1] dans l'article, ils évoquent néanmoins le risque qu'elle apparaisse également dans les autres échantillons du fait d'erreur dans la lecture de la séquençage de l'index lors de la phase de démultiplexage, ce qui est possible / cette séquence peut avoir un index similaire à un échantillon légitime (remplacement de tube, connaissance de protocole expérimental et des index prévus)
[^] # Re: Déformation journalistique
Posté par totof2000 . Évalué à 10.
Tout comme un site web peut être attaqué par les données qu'il manipule (saisies utilisateur), ou d'ailleurs n'importe quel programme qui manipumle des données peut être attaqué par ces données s'il est mal écrit. Le fait que ce soit de l'ADN, des données financières, ou n'importe quoi d'autre n'y change rien.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.