Demandes de tirage malveillantes

Qu'est-ce que Demandes de tirage malveillantes?

Une pull request malveillante attaque la révision, pas le code. Le changement est minime, la description est utile et une modification se trouve dans un fichier que la description ne mentionne jamais. Vous en soumettrez un vous-même : un véritable correctif de test instable, plus une ligne enfouie dans un script de déploiement qui envoie chaque variable CI à un serveur que vous contrôlez. Vous l'examinerez en tant que responsable, lirez chaque fichier modifié au lieu de vous fier au résumé. Ensuite, vous rendrez la capture structurelle avec CODEOWNERS, l'examen requis par le propriétaire du code et les limites sur les requêtes fork pull pouvant être exécutées.

Ce que vous apprendrez dans Demandes de tirage malveillantes

• Reconnaître le signal d'alarme d'une pull request malveillante : une modification d'un fichier qui n'a rien à voir avec ce que la modification prétend faire, cachée parmi des éléments de comparaison légitimes
• Comprendre pourquoi la lecture de la description de la pull request n'est pas suffisante et pourquoi un réviseur doit ouvrir et lire la comparaison complète de chaque fichier modifié
• Considérez les modifications hors de portée pour déployer, créer ou scripts CI comme un signal qui justifie un examen plus approfondi et plus sceptique.
• Appliquer le renforcement des politiques de révision : CODEOWNERS pour les fichiers sensibles, approbation requise de plusieurs réviseurs et limites sur les requêtes fork pull pouvant être exécutées.
• Comprendre pourquoi les requêtes d'extraction des forks se situent en dehors de la limite de confiance du projet et méritent un examen plus approfondi avant que leur code ne soit approuvé

Demandes de tirage malveillantes — Étapes de la formation

1. Dimensionner le projet

   Aujourd'hui, Bob cible Fennroot, un projet d'outils de développement open source qui accepte les demandes d'extraction de n'importe qui. Il commence là où n'importe quel contributeur le ferait, sur le référentiel public de Harrow, l'outil de construction du projet. Un projet ouvert est une porte ouverte : n’importe qui peut le bifurquer, le modifier et ouvrir une pull request. Bob n'est pas là pour vous aider. Il souhaite que son code soit fusionné, et la révision par un mainteneur très occupé est la seule chose qui le gêne.

2. Fork et clone

   Bob copie le référentiel sur son propre compte et clone le fork localement, afin qu'il puisse apporter ses modifications et les repousser sous forme de demande d'extraction. Son plan est simple : inclure un changement véritablement utile comme couverture et en cacher un deuxième, sans rapport, à côté.

3. La couverture et la cible

   La couverture de Bob est réelle : il corrige un test de nouvelle tentative vraiment instable, le genre de petite contribution qu'un projet accueille favorablement. Ce changement est honnête et utile, et c’est là tout l’intérêt. Cela donne à la pull request un aspect routinier. Sa véritable cible est un dossier totalement différent. Il ouvre le script de déploiement, qui n'a rien à voir avec un test, et le lit proprement.

4. Plantez la porte dérobée

   Bob ajoute une seule ligne au script de déploiement. Cela ressemble à un morceau de télémétrie de construction inoffensif, mais il envoie chaque variable d'environnement à un serveur qu'il contrôle. Le script de déploiement s'exécute dans le CI du projet, où ces variables incluent les clés de déploiement et les jetons de registre. Une ligne, dans un fichier, la demande d'extraction ne la mentionne jamais. C'est toute l'attaque.

5. Enterré à la vue de tous

   La ligne ressemble à quelque chose qu'un ingénieur de construction pourrait ajouter, et elle fait partie des étapes de déploiement ordinaires. Rien dans celui-ci ne crie à l’attaque, c’est exactement pourquoi il survit à un survol rapide.

6. Valider les deux modifications

   Bob prépare et valide les deux modifications ensemble : le véritable correctif de test et la ligne de script de déploiement, en une seule validation. Regroupés, les changements malveillants s’installent sur le dos des changements honnêtes.

7. Pousser jusqu'à la fork

   Bob pousse la branche jusqu'à sa fork. Le push va vers sa propre copie du référentiel, et la plateforme répond avec un lien pour ouvrir une pull request contre Fennroot.

8. Ouvrir la pull request

   Bob ouvre la pull request sur le référentiel de Fennroot. Il écrit un titre et une description qui parlent uniquement du test irrégulier et ne mentionnent jamais le script de déploiement. Le correctif de test est l'histoire qu'il souhaite que le critique lise. La porte dérobée en est complètement exclue.

9. Coup de pouce pour une fusion

   La demande d'extraction étant ouverte, Bob ajoute un commentaire amical pour une fusion rapide. Il le laisse sur la ligne de test, donc l'œil du réviseur se pose là et non sur le script de déploiement. Un peu de pression sociale pour approuver rapidement, avant que quiconque ne lise de trop près.

10. Contrôle des connaissances

    Vous venez de regarder une porte dérobée se transformer en une pull request derrière un véritable correctif. Expliquez pourquoi c'est dangereux.