Question:
Exemple de porte dérobée soumise à un projet open source?
swrittenb
2012-10-29 19:45:31 UTC
view on stackexchange narkive permalink

Pour clarifier immédiatement, je ne suis pas intéressé à écrire une porte dérobée. Je n'ai aucun intérêt à soumettre moi-même des listes de modifications de porte dérobée aux projets.

Je recherche des techniques de modélisation de source, et nous sommes intéressés à voir si des exploits ou du code malveillant peuvent être identifiés. Nous utilisons les historiques git et subversion pour examiner comment un instantané de modèle capture les relations entre le code. Il y a une question de savoir si certains types de code apparaissent comme des valeurs aberrantes dans un environnement comme celui-ci.

Dans cet esprit, j'ai du mal à trouver des instances d'un git / cvs /? dépôt open source avec un exemple de liste de modifications contenant une porte dérobée, et qui a été soumise et apparaîtra dans les journaux.

Nous regardions proftpd comme un premier exemple, mais cet exploit n'a pas été archivé mais a plutôt modifié d'autres versions du code.

Y a-t-il des exemples dans l'historique des révisions d'un projet open source de tentatives d'insertion de code de porte dérobée?

Remarque : J'ai soumis ceci à StackOverflow il y a quelque temps, mais il a été fermé. Je revisite ceci maintenant, et la recommandation était de demander ici. Merci!

Quatre réponses:
Bruce Ediger
2012-10-29 20:34:17 UTC
view on stackexchange narkive permalink

Quelques notes sur une tentative d’introduire une porte dérobée dans le noyau Linux, vers 2003. Apparemment sans succès. Le commentaire contemporain était assez intéressant.

Les machines de distribution du noyau Linux ont été à nouveau compromises en 2011, mais il semble qu'aucun code n'ait été modifié cette fois-là.

MISE À JOUR: On dirait qu'un miroir sourceforge avait une version de phpMyAdmin avec une porte dérobée intégrée.

+1 putain, j'allais publier le lien sur le noyau Linux et phpmyadmin.
sh4d0w
2012-10-31 14:46:06 UTC
view on stackexchange narkive permalink

Il y avait une porte dérobée dans le CMS e107 en 2010: http://www.esecurityplanet.com/headlines/article.php/3860981/Backdoor-Found-in-e107.htm

Il y a deux mois (septembre 2012), phpmyadmin avait une porte dérobée depuis l'un des dépôts / miroirs SourceForge: http://sourceforge.net/blog/phpmyadmin-back-door/

Le FBI aurait prétendu avoir détourné la pile IPSEC d'OpenBSD en 2000: http://bsd.slashdot.org/story/10/12/15/004235/FBI-Alleged-To-Have-Backdoored-OpenBSDs- IPSEC-Stack

OpenSource a beaucoup d'avantages par rapport à la source fermée, mais cela ne signifie pas qu'un projet open source pourrait être sûr en raison de sa nature. Des tests de pénétration continus sont indispensables.

Merci pour le lien de la pile OpenBSD IPSEC. Je m'en souviens vaguement. Est-ce que quelque chose est ressorti de cette allégation? J'ai cherché sur Google pendant un moment et j'ai trouvé un tas de dénégations, mais rien de définitif.
Rien pour les masses.
kqw
2015-11-07 05:54:21 UTC
view on stackexchange narkive permalink

La keynote FOSDEM 2014 de Poul-Henning Kamp (architecte principal de Varnish et Ntimed) est très intéressante:

Ceci est un briefing fictif de la NSA que j'ai donné comme discours de clôture au FOSDEM 2014

L'intention était de faire rire et réfléchir les gens, mais je mets au défi quiconque de le prouver.

C'est de la fiction , mais c'est de la fiction de quelqu'un qui a beaucoup d'expérience dans les projets open source.

Voici la vidéo de 45 minutes.

Et puis il y a Comment la NSA a (peut-être) mis une porte dérobée dans la cryptographie de RSA: une introduction technique sur le blog de CloudFlare.

AJ Henderson
2012-10-30 01:19:56 UTC
view on stackexchange narkive permalink

Je pense que la plus grande protection offerte par la plupart des projets open source est simplement de savoir qui a accès. Comme tout le monde ne peut généralement pas valider du code dans un projet, ceux qui ont reçu un accès de validation eux-mêmes ont tendance à être suffisamment actifs pour que cela ne vaille pas la peine d'essayer de faire des compromis de cette façon. (Il est plus facile d'essayer de trouver un exploit existant puisque la source est disponible.) Même si vous deviez essayer de faire un commit abusif, vous feriez beaucoup d'efforts et vous feriez face à une chance décente que votre commit escroc soit détecté par d'autres avant d'atteindre une version majeure, vous brûlant ainsi du projet et abandonnant tout le travail que vous avez fait.

Fondamentalement, parce que la difficulté est élevée et que le potentiel de récompense est faible, il n'est tout simplement pas ça ne vaut pas la peine d'essayer de compromettre un projet open source par malveillance. Le seul endroit où vous pourriez le voir tenté (du point de vue du risque par rapport à la récompense) serait que le gouvernement essaie de le faire, mais dans ce cas, ce serait probablement avec au moins un certain niveau de soutien au projet et serait soigneusement dissimulé. Il serait également très difficile de se passer d'une éventuelle détection pour la plupart des logiciels, c'est donc assez peu probable même dans ce cas.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...