9,90 € TTC
p. 06 Mettre en place un programme de Security Champions
p. 12 Embarquez un peu de Lua dans vos projets C
p. 22 NativePHP : développez des applications desktop en PHP !
p. 38 Écrire son premier pilote pour OpenBSD
p. 50 Manipulons les caractères avec iconv
p. 54 Les « tourments de la monopile », ou le « Single-Stack Syndrome »
p. 69 Les codes fantastiques : C for surprenant
p. 70 Le temps sous Linux - 1er volet
XZ Utils !
On voit beaucoup de raccourcis et de fausses vérités concernant cette backdoor que certains n’hésitent pas à qualifier de « backdoor SSH ». Que les choses soient claires, OpenSSH n’a, à la base, aucune dépendance vers xz/liblzma. C’est en réalité quelque chose d’ajouté pour intégrer plus facilement le serveur SSH en supportant les notifications systemd.
Oui, OpenSSH est patché pour s’intégrer plus facilement et c’est là, non pas la cause du problème, mais clairement une brique importante. Il ne s’agit pas là de « systemd bashing », même si cela serait aussi facile que tentant. En réalité, systemd est tellement « présent » dans la plupart des distributions GNU/Linux que n’importe quel problème peut être lié à ce qui était, fut un temps, un système d’init. On pourrait parfaitement, de la même façon, imputer ce blâme aux autotools dont la complexité n’est plus à démontrer, et qui est aussi une composante critique de cette backdoor.
En réalité, le problème est une combinaison d’un ensemble de paramètres, techniques, humains et fonctionnels, parfaitement alignés qui, combinés avec une approche sournoise et patiente des attaquants, a conduit à cette situation. Situation qui, je le rappelle, aurait pu être bien pire si la curiosité d’Andres Freund ne l’avait pas poussé à chercher pourquoi ses processus sshd consommaient plus de CPU que d’habitude.
Pour moi, trois choses sont importantes dans cette triste affaire. Premièrement, c’est la complexité qui a permis la dissimulation et a failli provoquer une réelle catastrophe. Plus on s’éloigne de KISS, plus la dissimulation est aisée. Ensuite, c’est bel et bien la « supply chain » qui a été attaquée et on se retrouve donc à nouveau dans un contexte très similaire à la situation connue il y a peu avec Log4Shell.
Et enfin, et c’est sans doute le plus important quoi qu’en disent certains, c’est bien le caractère open source du projet est ce qui a permit la détection de la backdoor, non ce qui en est la cause ! C’est parce que n’importe qui peut auditer le code, et le système de build, que ce genre d’attaque est rendu difficile, et non l’inverse ! Ceux qui affirment le contraire sont soit d’une mauvaise foi édifiante, soit sont totalement perdus dans leur biais de confirmation malsain. Point.
Et pour l'amour du ciel... Il n'y a pas de backdoor dans OpenSSH !
Denis Bodor
GNU/Linux Magazine s'adresse aux professionnels et aux particuliers désireux de mieux maîtriser les techniques et problématiques liées à la programmation et à l’utilisation de solutions open source. Tous les deux mois avec ses articles techniques, la publication couvre les thématiques suivantes : programmation système, algo, bas niveau, sécurité du code, développement web...
Soyons clairs, je ne suis pas fan de Lua en tant que langage de programmation. Le simple fait que les tableaux débutent à l'indice 1 me perturbe totalement et constitue pour moi une véritable aberration. Mais, d'un autre côté, Lua est aussi le langage par excellence lorsqu'il s'agit d'embarquer des fonctionnalités de scripting au sein d'une application ou d'un outil. Du moins, c'est ce que tend à montrer sa popularité dans ce domaine et, si l'on n’a jamais tenté l'expérience, on peut se demander pourquoi. La réponse est évidente après quelques lignes de code et on se surprend soi-même à dire, à haute voix qui plus est, « Ah ! Mais c'est excellent, en fait ! ».
Si vous croyez que le format ASCIIZ (aussi appelé « chaîne de caractères à terminateur nul » à la base du langage C et d’UNIX) est le pire péché originel de l’informatique, accrochez-vous. Il est amplifié par un autre péché bien plus grave, commis au nom du minimalisme, excusé au nom de la compatibilité et perpétué par l’oubli des alternatives. Si vous avez lu l’article de mars 2023 [1] jusqu’au bout, vous avez probablement compris que la plupart des langages de programmation actuels n’utilisent qu’une seule pile. C’est la source de nombreux problèmes (de sûreté, de sécurité, de complexité et bien d’autres) aux origines de failles variées (représentant peut-être un cinquième des CVE) que nous sommes habitués à mitiger, sans les résoudre vraiment. Dans cette première partie lovecraftienne, nous irons jusqu’au fond de l’impasse pour démontrer l’absurdité, les difficultés et les dangers imposés par ce système.
PHP, c'est bien connu, est un langage de script dédié aux traitements d'un serveur web. Mais n'est-ce bien que cela ? Avec NativePHP, la donne change, car il est maintenant possible de développer des applications pour GNU/Linux, Windows et macOS.