Certains développeurs encrassent les logiciels open source

L'une des choses les plus étonnantes à propos de l'open source n'est pas qu'il produit d'excellents logiciels. C'est que tant de développeurs mettent leur ego de côté pour créer d'excellents programmes avec l'aide des autres. Maintenant, cependant, une poignée de programmeurs font passer leurs propres préoccupations avant le bien des nombreux logiciels open source potentiellement dévastateurs pour tout le monde.

Par exemple, Brandon Nozaki Miller, responsable du gestionnaire de packages JavaScript RIAevangelist, a écrit et publié un paquet de code source npm open-code appelé peacenotwar. Il n'a fait qu'imprimer un message de paix aux ordinateurs de bureau. Jusqu'ici, si inoffensif. 

Miller a ensuite inséré un code malveillant dans le package pour écraser les systèmes de fichiers des utilisateurs si leur ordinateur avait une adresse IP en Russie ou en Biélorussie. Il l'a ensuite ajouté comme dépendance à son populaire nœud-ipc programme et chaos instantané ! De nombreux serveurs et PC sont tombés en panne lors de la mise à jour du code le plus récent, puis leurs systèmes ont vu leurs disques effacés. 

La défense de Miller, "Tout cela est public, documenté, sous licence et open source", ne tient pas. 

Liran Tal, le Snyk chercheur qui a découvert le problème a déclaré : « Même si l'acte délibéré et dangereux [est] perçu par certains comme un acte de protestation légitime, comment cela se répercute-t-il sur la réputation future du mainteneur et participation à la communauté des développeurs ? Ferait-on à nouveau confiance à ce mainteneur pour qu'il ne donne pas suite à de futurs actes dans de telles actions ou même des actions plus agressives pour tous les projets auxquels il participe ? » 

Miller n'est pas une manivelle aléatoire. Il a produit beaucoup de bon code, comme node-ipc, et Serveur HTTP de nœud. Mais pouvez-vous faire confiance à l'un de ses codes pour ne pas être malveillant ? Alors qu'il le décrit comme "pas un logiciel malveillant, [mais] un logiciel de protestation qui est entièrement documenté», d'autres sont en désaccord avec venin. 

Comme l'a écrit un programmeur GitHub : « Ce qui va se passer, c'est que les équipes de sécurité des entreprises occidentales qui n'ont absolument rien à voir avec la Russie ou la politique vont commencer à voir logiciels libres et open source comme vecteur d'attaques de la chaîne d'approvisionnement (ce qui est totalement le cas) et commencer simplement à interdire les logiciels libres et open source - tous les logiciels libres et open source - au sein de leurs entreprises. 

Comme l'a écrit un autre développeur GitHub avec le handle nm17, "Le facteur de confiance de l'open source, qui était basé sur la bonne volonté des développeurs est maintenant pratiquement disparu, et maintenant, de plus en plus de gens se rendent compte qu'un jour, leur bibliothèque/application pourra éventuellement être exploitée pour faire/dire tout ce que certains développeurs aléatoires sur Internet pensaient ' était la bonne chose à faire.

Les deux font des points valables. Lorsque vous ne pouvez pas utiliser le code source à moins d'être d'accord avec la position politique de son créateur, comment pouvez-vous l'utiliser en toute confiance ? 

Le cœur de Miller est peut-être au bon endroit : Slava Ukraini ! – mais un logiciel open source infecté par une charge utile malveillante est-il le bon moyen de protéger l'invasion russe de l'Ukraine ? Non ce n'est pas. 

La méthode open-source ne fonctionne que parce que nous nous faisons confiance. Lorsque cette confiance est rompue, quelle qu'en soit la cause, le cadre fondamental de l'open source est rompu. Comme l'a déclaré Greg Kroah-Hartman, le responsable du noyau Linux pour la branche stable, lorsque des étudiants de l'Université du Minnesota ont délibérément tenté d'insérer du mauvais code dans le noyau Linux pour une expérience en 2021, "Ce qu'ils font est un comportement malveillant intentionnel et n'est pas acceptable et totalement contraire à l'éthique.

Les gens soutiennent depuis longtemps que l'open source devrait également inclure des dispositions éthiques. Par exemple, 2009 Licence publique générale d'exception (eGPL), une révision de la GPLv2, a tenté d'interdire aux «exceptions», telles que les utilisateurs et les fournisseurs militaires, d'utiliser son code. Ça a échoué. D'autres licences telles que la Licence JSON avec sa clause gentiment naïve "le logiciel doit être utilisé pour le bien, pas le mal" toujours en vigueur, mais personne ne l'applique.  

Plus récemment, l'activiste et développeur de logiciels Coraline Ada Ehmke a introduit une licence open source qui oblige ses utilisateurs à agir moralement. Plus précisément, elle Licence hippocratique ajoutée à la Licence open source MIT une clause stipulant : 

"Le logiciel ne peut pas être utilisé par des individus, des entreprises, des gouvernements ou d'autres groupes pour des systèmes ou des activités qui mettent activement et sciemment en danger, nuisent ou menacent autrement le bien-être physique, mental, économique ou général d'individus ou de groupes défavorisés dans violation de la Déclaration universelle des droits de l'homme des Nations Unies.

Ça sonne bien, mais ce n'est pas open source. Vous voyez, l'open source est en soi une position éthique. Son éthique est contenue dans le Fondation du logiciel libre (FSF)'s Quatre libertés essentielles. C'est la base de toutes les licences open source et de leur philosophie de base. En tant qu'expert juridique open source et professeur de droit à Columbia, Eben Moglen, a déclaré à l'époque que les licences éthiques ne peuvent pas être des logiciels libres ou des licences open source : 

"Liberté zéro, le droit d'exécuter le programme à quelque fin que ce soit, vient en premier parmi les quatre libertés, car si les utilisateurs n'ont pas ce droit en ce qui concerne les programmes informatiques qu'ils exécutent, ils n'ont finalement aucun droit sur ces programmes. Les efforts visant à autoriser uniquement les bonnes utilisations, ou à interdire les mauvaises aux yeux du donneur de licence, violent l'exigence de protéger la liberté zéro. 

En d'autres termes, si vous ne pouvez pas partager votre code pour une raison quelconque, votre code n'est pas vraiment open source. 

Un autre argument plus pragmatique concernant l'interdiction à un groupe d'utiliser un logiciel open source est que le blocage de quelque chose comme une adresse IP est un pinceau très large. Comme Florian Roth, société de sécurité Systèmes Nextron' Responsable de la Recherche, qui considérait “désactiver mes outils gratuits sur les systèmes avec certains paramètres de langue et de fuseau horaire », a finalement décidé de ne pas le faire. Pourquoi? Car ce faisant, «on désactiverait aussi les outils sur les systèmes des critiques et des libres penseurs qui condamnent les actions de leurs gouvernements. 

Malheureusement, ce ne sont pas seulement les gens qui essaient d'utiliser l'open source pour ce qu'ils considèrent comme un objectif éthique supérieur qui causent des problèmes aux logiciels open source. 

Plus tôt cette année, le développeur JavaScript Marak Squires a délibérément saboté ses bibliothèques Javascript open source obscures, mais d'une importance vitale, « colors.js » et « faker.js ». Le résultat? Des dizaines de milliers de programmes JavaScript ont explosé.

Pourquoi? Ce n'est pas encore tout à fait clair, mais dans un article GitHub supprimé depuis, Squires a écrit : « Respectueusement, Je ne soutiendrai plus les Fortune 500 (et d'autres petites entreprises) avec mon travail gratuit. Il n'y a pas grand-chose d'autre à dire. Profitez-en pour m'envoyer un contrat annuel à six chiffres ou bifurquez le projet et demandez à quelqu'un d'autre de travailler dessus. Comme vous pouvez l'imaginer, cette tentative de chantage pour obtenir un chèque de paie n'a pas si bien fonctionné pour lui. 

Et puis il y a des gens qui mettent délibérément des logiciels malveillants dans leur code open source pour le plaisir et le profit. Par exemple, la société de sécurité DevOps JFrog a découvert 17 nouveaux packages malveillants JavaScript dans le référentiel NPM qui attaquent et volent délibérément les jetons Discord d'un utilisateur. Ceux-ci peuvent ensuite être utilisés sur le Plateforme de communication et de distribution numérique Discord.

En plus de créer de nouveaux programmes open source malveillants qui semblent innocents et utiles, d'autres attaquants prennent d'anciens logiciels abandonnés et les réécrivent pour inclure des portes dérobées de vol de crypto-monnaie. L'un de ces programmes était le flux d'événements. Un code malveillant y a été inséré pour voler des portefeuilles Bitcoin et transférer leurs soldes vers un serveur de Kuala Lumpur. Il y a eu plusieurs épisodes similaires au fil des ans.

Avec chacun de ces mouvements, la confiance dans les logiciels open source s'épuise. Puisque l'open-source est absolument vital pour le monde moderne, c'est une mauvaise tendance. 

Que pouvons-nous y faire? Eh bien, d'une part, nous devrions considérer très attentivement quand, le cas échéant, nous devrions bloquer l'utilisation de code open source. 

Plus concrètement, nous devons commencer à adopter l'utilisation de Fondation Linux Échange de données sur les progiciels (SPDX) et Nomenclature logicielle (SBOM). Ensemble, ils nous diront exactement quel code nous utilisons dans nos programmes et d'où il vient. Ensuite, nous serons beaucoup plus en mesure de prendre des décisions éclairées.

Aujourd'hui, très souvent, les gens utilisent du code open source sans savoir exactement ce qu'ils exécutent ou sans le vérifier pour les problèmes. Ils supposent que tout va bien avec ça. Cela n'a jamais été une hypothèse intelligente. Aujourd'hui, c'est carrément idiot. 

Même avec tous ces changements récents, l'open source est toujours meilleur et plus sûr que les alternatives logicielles propriétaires de la boîte noire. Mais, nous devons vérifier et vérifier le code au lieu de lui faire aveuglément confiance. C'est la seule chose intelligente à faire pour aller de l'avant.

Histoires connexes: