Après heartbleed il y a des choses qui ont était faites de manière plus général (il y a FOSSA dont je parlais plus haut, mais la linux fondation aussi avait fais des choses).
C'est l'arbre qui cache la forêt franchement. C'est bien, c'est sûr mais ciblé sur quelques composants.
Les composants qui terminent dans des tonnes d'applications, il y en a des milliers. Et beaucoup d'entre eux sont maintenus par des toutes petites équipes en mode arrache. Et il en suffit d'un.
Log4j 2 est un exemple intéressant car c'est un projet Apache, qui a des règles plutôt strictes de revue, de votes, d'intégration dans les équipes... Donc globalement un projet sain et plutôt sécurisant. Et la faille est due à de la maladresse, pas de la malveillance.
Mais pour chaque composant utilisé, il faut être sûr du code existant, sûr de l'équipe et sûr du futur du composant et que l'équipe ne sera jamais gangrénée (on a vu quelques attaques côté npm, où quelqu'un qui paraissait de bonne volonté a repris la maintenance d'un composant largement utilisé pour finalement y inclure une faille volontairement bien après), d'autant qu'on met de plus en plus les composants à jour automatiquement (Dependabot, Renovate).
Note que je n'ai pas de solution miracle. Je pointe juste un problème systémique qui va avec la réutilisation massive de composants et aussi leurs multiplications. Je pense qu'au début de l'Open Source, c'était plus compliqué de mettre en place ce genre de vecteur parce que rien que mettre en place ton infra de développement, release, te faire connaître, ça demandait du temps et un sacré effort. C'est beaucoup plus facile maintenant. Ca a de très bons côtés mais aussi des composantes qui demandent de la prudence.
Les GitHub Actions sont un excellent exemple : GitHub fournit très très peu de GitHub Actions standards et facilite la mise en place d'un écosystème d'actions. Et ça fleurit dans tous les sens avec plein de gens qui réutilisent des actions déjà faites sans les regarder car très pratique. Au niveau de ton repository, tu pointes vers un repo externe généralement vers une version glissante (donc le code de l'action peut évoluer dans le temps) et tu utilises cette action pour builder/releaser. Il est super facile d'utiliser la dite action pour injecter du code, par exemple dans un workflow de release pour que ce soit discret (tu verrais facilement une manipulation de la branche main mais pour un tag c'est hyper discret).
L'Open Source repose beaucoup sur le modèle scientifiquement appelé "modèle Bisounours" où le monde entier est gentil et essaie de faire avancer tout le monde. Jusqu'à présent, ça marche plutôt bien. Mais c'est super super fragile si on commence à introduire des gens mal intentionnés qui ont du temps dans le bazar. Espérons qu'ils restent occupés à miner des bitcoins :)
Personnellement, je suis plutôt surpris qu'il y ait si peu d'attaques de ce genre. Pour l'instant, la majorité de celles qu'on connaît ont touché l'écosystème Javascript.
[^] # Re: Ca vaut ce que ça vaut mais...
Posté par Guillaume Smet (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 2.
C'est l'arbre qui cache la forêt franchement. C'est bien, c'est sûr mais ciblé sur quelques composants.
Les composants qui terminent dans des tonnes d'applications, il y en a des milliers. Et beaucoup d'entre eux sont maintenus par des toutes petites équipes en mode arrache. Et il en suffit d'un.
Log4j 2 est un exemple intéressant car c'est un projet Apache, qui a des règles plutôt strictes de revue, de votes, d'intégration dans les équipes... Donc globalement un projet sain et plutôt sécurisant. Et la faille est due à de la maladresse, pas de la malveillance.
Mais pour chaque composant utilisé, il faut être sûr du code existant, sûr de l'équipe et sûr du futur du composant et que l'équipe ne sera jamais gangrénée (on a vu quelques attaques côté npm, où quelqu'un qui paraissait de bonne volonté a repris la maintenance d'un composant largement utilisé pour finalement y inclure une faille volontairement bien après), d'autant qu'on met de plus en plus les composants à jour automatiquement (Dependabot, Renovate).
Note que je n'ai pas de solution miracle. Je pointe juste un problème systémique qui va avec la réutilisation massive de composants et aussi leurs multiplications. Je pense qu'au début de l'Open Source, c'était plus compliqué de mettre en place ce genre de vecteur parce que rien que mettre en place ton infra de développement, release, te faire connaître, ça demandait du temps et un sacré effort. C'est beaucoup plus facile maintenant. Ca a de très bons côtés mais aussi des composantes qui demandent de la prudence.
Les GitHub Actions sont un excellent exemple : GitHub fournit très très peu de GitHub Actions standards et facilite la mise en place d'un écosystème d'actions. Et ça fleurit dans tous les sens avec plein de gens qui réutilisent des actions déjà faites sans les regarder car très pratique. Au niveau de ton repository, tu pointes vers un repo externe généralement vers une version glissante (donc le code de l'action peut évoluer dans le temps) et tu utilises cette action pour builder/releaser. Il est super facile d'utiliser la dite action pour injecter du code, par exemple dans un workflow de release pour que ce soit discret (tu verrais facilement une manipulation de la branche main mais pour un tag c'est hyper discret).
L'Open Source repose beaucoup sur le modèle scientifiquement appelé "modèle Bisounours" où le monde entier est gentil et essaie de faire avancer tout le monde. Jusqu'à présent, ça marche plutôt bien. Mais c'est super super fragile si on commence à introduire des gens mal intentionnés qui ont du temps dans le bazar. Espérons qu'ils restent occupés à miner des bitcoins :)
Personnellement, je suis plutôt surpris qu'il y ait si peu d'attaques de ce genre. Pour l'instant, la majorité de celles qu'on connaît ont touché l'écosystème Javascript.