Actu & People

p. 06 Le Ć, un langage pour générer du code dans d’autres langages ?

Scripting zone

p. 10 Protobuf avec Ruby : je suis tombé sur un buffer !

IA & Data Science

p. 14 Gradient Boosting : une introduction

Autour du Code

p. 24 Suivez les performances de vos applications Django avec Elastic APM

Sécu & Hack

p. 36 Ce n’est pas en saupoudrant du cumin que l’on attrape du PKCS11

Système & Bas Niveau

p. 52 Les namespaces network et PID

Webdev

p. 72 Acquisition sur le terrain et dissémination d’informations et photographies géoréférencées par le Web : qgis2web et QField

CVE-2021-4034

Cette entrée CVE restera dans l’histoire comme une réelle aberration. Elle désigne en effet une vulnérabilité découverte dans l’outil pkexec, de la boîte à outils Polkit, permettant à n’importe quel utilisateur local d’élever ses privilèges illégalement.

De telles vulnérabilités existent partout, mais ce qui rend celle-ci particulière est non seulement le fait qu’elle existe depuis près de 12 ans sans que personne ne la remarque, mais aussi, et surtout, qu’elle découle d’une erreur de programmation parfaitement classique où le nombre d’arguments (argc) est mal géré, et où argv [1] fini par être utilisé pour invoquer un execve() avec des données invalides. Ceci est littéralement un cas d’école.

À qui jeter la pierre ? Aux développeurs de Polkit à l’origine du bug ? Au langage C permettant ce genre d’erreur ? Au noyau Linux qui autorise un execve() quand argc est 0 (contrairement à OpenBSD) ? Aux experts en sécurité ne s’étant jamais penchés méticuleusement sur tous ces programmes SUID/SGID root ? Aux millions d’utilisateurs et développeurs n’ayant jamais regardé les sources de ce qu’ils utilisent ? Pourquoi pas à vous, pourquoi pas à moi, qui faisons de même ?

Certains n’hésiteraient pas à dire que cette grave vulnérabilité, en particulier juste après celle découverte dans Log4j, porte préjudice à l’image qualitative de l’open source et du logiciel libre. Il n’y a rien de plus faux, car ce serait oublier que les clauses de limitation de garantie ne sont pas là par hasard : l’utilisateur est responsable de ce qu’il utilise parce que, justement, il en a les moyens grâce aux droits que lui confère la licence.

Mais la vraie question n’est pas là. Cette faille a été découverte précisément parce que les sources de pkexec sont disponibles afin d’être auditées. Qu'en est-il de ce qui n’est pas vérifiable ? Combien de failles du même type, avec la même origine et les mêmes conséquences n’ont pas été, ne sont pas et ne seront sans doute jamais publiquement découvertes et corrigées ? Ces personnes à la critique facile pensent-elles vraiment que des développeurs qui n’ont pas à se soucier du regard de leurs pairs (à part peut-être celui d’un chef de projet, obsédé par les CR et les PKI, et dont les glorieuses années de hacking sont un lointain, sinon imaginaire, passé) sur leurs sources font miraculeusement moins d’erreurs ? J’en doute, bien au contraire.

Oui, cette faille est bien malheureuse, mais mieux vaut tard (open source) que jamais (propriétaire) !

Denis Bodor