# Regex Crossword: Mets de l’expression régulière dans tes mots croisés
Par Frédéric Lambot
Petite découverte du mois, qui, à ma grande surprise, existe depuis quelques temps: Regex Crossword, un jeu de mots croisés disponible sur plusieurs plate-formes :
Le but du jeu ? Facile.
Un indice sous forme d’expression régulière en vertical, un autre en horizontal et hop, la solution au croisement des deux.
Plusieurs niveaux de difficulté sont disponibles.
C’est, mine de rien, une très bonne façon pour les débutants de découvrir les expressions régulières et pour les experts de faire briller leurs compétences.
# Turborepo & Svelte « chez » Vercel
Par Guillaume Poittevin
Coup sur coup, le 11 novembre puis le 9 décembre, Vercel a accueilli deux pointures de l’écosystème Javascript.
En premier c’est Rich Harris qui a rejoint les équipes du créateur de Next.js. Comme annoncé sur leur blog, cela permettra au créateur de Svelte de se consacrer à plein temps au développement du Framework le plus aimé selon Stackoverflow.
Début décembre c’est Turborepo et son créateur qui ont rejoint l’entreprise Californienne, Jared Palmer apportera donc toute son expérience au service des projets de Vercel.
Cette annonce a été l’occasion de découvrir l’existence de Turborepo, avec une possibilité à court terme de donner sa chance à l’outil aux promesses plus qu’alléchantes. La gestion d’une base de code Typescript contenant de nombreux composants Angular n’étant aujourd’hui pas si simple avec nos outils en place, il est plus que probable que nous puissions faire mieux avec un outil taillé pour.
# Vulnérabilités à la chaîne dans Log4j
Par Thomas Broyer
Fin novembre, l’équipe sécurité d’Alibaba Cloud découvre une vulnérabilité dans Log4j 2 touchant toutes les versions depuis 2.0-beta9 et permettant une exécution de code à distance et/ou une exfiltration de données, et a suivi le processus de divulgation responsable pour informer les développeurs du projet (l’entreprise sera d’ailleurs sanctionnée par le gouvernement chinois pour ne pas leur en avoir donné la primeur !).
Ceux-ci commencent de suite à travailler sur un correctif, qui sera repéré (le développement se faisant en public sur GitHub) et divulgué plus largement le 10 décembre, avec une preuve de concept d’exploitation, avant même la publication finale d’une version corrigée, créant une forme de psychose généralisée, la nouvelle se répandant à la veille du week-end. Cette vulnérabilité sera nommée Log4shell par certains acteurs, ou plus sobrement CVE-2021-44228, et n’est donc pas à proprement parler une 0-day.
Le lundi suivant, d’autres chercheurs découvrent que le correctif proposé dans la nouvelle version 2.15.0, ainsi que la solution de contournement pour certaines versions précédentes, ne sont pas suffisants, et une nouvelle version 2.16.0 est publiée le jour même (ainsi qu’une version 2.12.2 compatible avec Java 7) pour corriger cette nouvelle faille CVE-2021-45046, faille dont la criticité jugée initialement modérée a finalement été relevée à critique en fin de semaine !
Au même moment, un troisième bug est découvert, toujours dans cette fonctionnalité de lookups, qui peut mener à un déni de service (CVE-2021-45105), et une nouvelle version 2.17.0 est publiée dans la foulée. Puis une quatrième version 2.17.1 verra le jour entre Noël et le Jour de l’An pour corriger une faille supplémentaire (CVE-2021-44832), dans la continuité des précédentes.
Cet épisode nous rappelle la situation HeartBleed d’OpenSSL au printemps 2014 : une poignée de développeurs, tous bénévoles, maintiennent sur leur temps libre un composant logiciel utilisé par des millions à travers le monde (la Fondation Apache se vantait en juin dernier que Log4j était même utilisé dans Ingenuity, l’hélicoptère martien).
En l’occurrence, nous avons ici affaire à une erreur de conception, et un empilement de fonctionnalités : la fonctionnalité initiale prévoyait l’interpolation de variables d’environnement dans les messages, présente dès la toute première version alpha de Log4j 2, mais telle qu’implémentée elle interpolait également ces variables dans les paramètres du message, contenant généralement des valeurs contrôlées par les utilisateurs ; c’était probablement un bug puisqu’aucun test n’utilisait les paramètres de message ; puis d’autres interpolations ont été ajoutées sans prendre la mesure de la portée de la fonctionnalité, jusqu’à la version 2.0-beta9 qui ajoutera une interpolation JNDI permettant l’appel à un serveur externe et par conséquent une forme de SSRF (Server-Side Request Forgery, qui permet ici d’exfiltrer des données via la résolution DNS en profitant du fait que les lookups sont récursifs), ainsi que l’injection de classe Java (c’est une fonctionnalité, contestable, de JNDI) et donc une exécution de code à distance.
On notera que Log4j 1 n’est pas vulnérable à cette attaque mais n’est plus maintenue depuis plusieurs années (et est vulnérable via son fichier de configuration). Logback, le successeur spirituel de Log4j 1 et du même auteur (Log4j 2 est un tout autre projet, après des désaccords entre les développeurs), n’est pas vulnérable non plus, mais son auteur a préféré publier une nouvelle version 1.2.8 dès le 14 décembre, puis une version 1.2.9 deux jours plus tard, supprimant tout code permettant une connexion à un serveur externe (JNDI ou JDBC) ainsi que la possibilité d’utiliser Groovy pour le fichier de configuration, code soutenant des fonctionnalités trop peu souvent utilisées, le jeu n’en valant pas la chandelle (ces versions corrigent les vulnérabilités dont souffrent Log4j 1 et 2, corrigées finalement deux semaines plus tard dans la version 2.17.1).
À la lumière de ces vulnérabilités en cascade dans Log4j 2, on peut se poser la question de migrer vers Logback, migration qui pourrait être plutôt aisée pour un grand nombre de projets. À vos analyses de risque !
Laisser un commentaire