Le carnet du grincheux

Tous les matins, un certain Dominique Seux sévit ver 07h45 sur France Inter. Ses chroniques vont de particulièrement intéressantes à totalement ineptes. Ce matin, nous avons été des petits gâtés, elle fut totalement inepte. Il était question de sécurité informatique, d'un pipe-line piraté par on ne sait qui aux États-Unis, de télétravail cible facile pour des pirates et de pandémie en général.

Mon cher Dominique, vous étiez totalement à côté du sujet et vous ne devriez parler que de ce que vous maîtrisez.

Les pirates informatiques existent depuis qu'existe l'informatique. Ils sont opportunistes et se sont développés avec elle. En revanche, ce ne sont pas forcément des flèches. La recrudescence des attaques actuelles n'est pas due à la massification de l'outil informatique, mais à son appauvrissement génétique déplorable. Elles sont aussi dues à la politique de Microsoft qui ne permet pas les mises à jours de systèmes anciens qui sont utilisés dans le milieu médical (il n'est pas rare de voir un équipement de radio, par exemple, ne fonctionner qu'avec Windows XP, j'en croise encore très régulièrement) et au fait que la sécurité informatique est toujours le parent pauvre (pourquoi les gens qui sont en télétravail n'auraient pas un simple VPN pour accéder aux serveurs de leur entreprise ?). Cela fait des années que les spécialistes alertent et prêchent dans le désert. Cela fait des années qu'ils alertent en disant que si le terrorisme international s'allie avec une bande de pirates, cela pourrait faire mal. Tant qu'il n'y aura pas une catastrophe d'ampleur, rien ne changera parce qu'il y a une raison financière derrière cela.

Lorsque j'ai débuté dans le métier de l'électronique, la conception d'un produit complexe passait par une étude poussée et on mettait en regard du cahier des charges des composants permettant d'atteindre le but recherché. Une fois que c'était fait, on attaquait la conception des cartes puis le code embarqué. Aujourd'hui, on fonctionne à l'envers. On passe directement du cahier des charges à l'écriture des programmes en utilisant des briques toutes faites, qu'il s'agisse de cartes électroniques, de systèmes d'exploitation ou de bibliothèques dont plus personne dans les équipes de développement ne connaît les limites. Et c'est aussi comme cela qu'on a des circuits électroniques qui fonctionnent à 98% du temps, qu'il faut régulièrement réinitialiser. Je ne me souviens pas avoir une seule fois redémarré mon premier ordinateur, un Goupil G3/6809 durant toute son existence.

Pour fixer les idées, il m'est arrivé à plusieurs reprises à remettre des projets sur les bons rails, projets qui étaient tous sur une mauvaise pente en raison d'une erreur de base, à savoir de mauvais choix en terme d'architecture ou de logiciel. Là où on aurait utilisé dans les années 1980 un microprocesseur 6502, un 6809 ou pour les plus joueurs un 8085 avec un peu de ROM et de RAM, il n'est pas rare de voir dégainer aujourd'hui une carte-mère avec un processeur x86 ou un ARM quelconque, un système Linux embarqué, beaucoup de Go de stockage, plusieurs Go de RAM et une machine virtuelle Java par dessus. Le développement n'est pas cher, on n'a plus besoin de personnes qualifiées pour écrire du code, mais simplement de gens sachant à peu près empiler des briques préexistante. Le résultat est dramatique.

Pourquoi ?

Le noyau Linux est devenu un truc horrible avec des failles de sécurité potentielles à tous les coins du code (en particulier, la gestion des modules est déplorable avec des pointeurs NULL un peu partout). Même chose pour le système d'exploitation dans son intégralité. Ces failles sont parfaitement documentées et il existe sur internet des bouts de code permettant de lancer ces attaques sans trop de difficulté. Une fois une faille identifiée, elle pourra être utilisée sur tous les appareils connectées à un réseau quelconque utilisant la même version du noyau Linux. Les attaques se propagent toutes seules et on arrive aujourd'hui à avoir des systèmes Linux compromis lorsqu'ils sont gérés par des administrateurs systèmes un peu légers.

Le simple fait d'avoir du code écrit à façon, ou le simple fait d'avoir des firmwares génétiquement différents (pour les objets connectés, il est possible d'utiliser FreeRTOS, QNX Contiki et bien d'autres systèmes comme des noyaux L4 par exemple) et des architectures matérielles différentes régleraient ce problème. En effet, les attaques n'ont de sens que si le bénéfice qu'un pirate en retire est supérieur à l'énergie qu'il doit mettre pour arriver à ses fins. Être contraint d'étudier tous les systèmes à attaquer assez finement pour en découvrir les failles en découragera plus d'un rapidement. En ce sens, le fait d'avoir la majorité des serveurs sous Linux avec une architecture x86 est un risque inconsidéré. Le fait d'avoir des objets connectés qui ne peuvent pas être mis à jour facilement en est un autre (exemple : les smartphones sous Android qui, passé un certain temps, ne sont plus mis à jour par les constructeurs).

Et c'est comme cela qu'on se retrouve avec des ransomwares un peu partout. C'est aussi comme ça qu'on se retrouve dans un réseau de banques dont je tairais le nom à effectuer des opérations sensibles sur des clefs USB depuis que le cœur du réseau fonctionnant auparavant sous OpenVMS a été migré sous Windows Server.

Il est déjà trop tard. plus l'écosystème informatique en général (voitures autonomes comprises) s'appauvrira, plus le risque de terrorisme numérique deviendra grand. Pour lutter contre cela, une seule solution, refaire de la conception à l'ancienne. Ces développements coûtent un peu plus cher, mais nous prémunirait contre ce genre d'attaques.

Pourtant, on ne peut pas vraiment dire qu'on en prenne le chemin.