Bösartige Pull Requests

Was ist Bösartige Pull Requests?

Ein bösartiger Pull Request manipuliert das Review: Die Änderung wirkt klein, die Beschreibung plausibel, doch in einer unerwähnten Datei steckt eine Backdoor. Sie reichen selbst einen solchen Pull Request ein — mit einer echten Testkorrektur und einer versteckten Zeile im Deploy-Skript, die CI-Umgebungsvariablen an einen von Ihnen kontrollierten Server sendet. Anschließend prüfen Sie ihn als Maintainerin, lesen den Diff jeder Datei und ergänzen CODEOWNERS, verpflichtende Code-Owner-Freigaben sowie Beschränkungen für Pull Requests aus Forks.

Was Sie lernen in Bösartige Pull Requests

• Das Warnsignal eines bösartigen Pull Requests erkennen: eine Änderung an einer Datei, die mit dem angekündigten Zweck nichts zu tun hat und zwischen legitimen Diff-Hunks versteckt ist
• Verstehen, warum die Beschreibung eines Pull Requests nicht ausreicht und warum ein Reviewer den vollständigen Diff jeder geänderten Datei öffnen und lesen muss
• Unerwartete Änderungen an Deploy-, Build- oder CI-Skripten als Warnsignal erkennen und besonders gründlich prüfen
• Die Review-Richtlinie härten: CODEOWNERS für sensible Dateien, verpflichtende Freigabe durch mehr als einen Reviewer und Grenzen dafür, was Pull Requests aus Forks ausführen dürfen
• Verstehen, warum Pull Requests aus Forks außerhalb der Vertrauensgrenze des Projekts liegen und besonders genau geprüft werden müssen, bevor man ihrem Code traut

Bösartige Pull Requests — Trainingsschritte

1. Das Projekt auskundschaften

   Bob hat heute Fennroot im Visier, ein Open-Source-Projekt für Entwicklertools, das Pull Requests von allen annimmt. Er beginnt im öffentlichen Repository von Harrow, dem Build-Tool des Projekts. Jeder kann dieses Repository forken, ändern und einen Pull Request eröffnen. Bob will seinen Code einschleusen. Nur das Review einer vielbeschäftigten Maintainerin steht ihm im Weg.

2. Forken und klonen

   Bob forkt das Repository in sein eigenes Konto und klont den Fork lokal, damit er seine Änderungen vornehmen und sie als Pull Request zurückschicken kann. Sein Plan ist simpel: eine wirklich nützliche Änderung als Tarnung mitliefern und daneben eine zweite, themenfremde verstecken.

3. Die Tarnung und das Ziel

   Bobs Tarnung ist echt: Er behebt einen tatsächlich instabilen Retry-Test — ein kleiner, willkommener Beitrag. Gerade weil diese Änderung nützlich ist, wirkt der Pull Request unverdächtig. Sein eigentliches Ziel ist eine andere Datei. Er öffnet das Deploy-Skript, das mit dem Test nichts zu tun hat, und sieht es sich vor seiner Änderung an.

4. Die Backdoor einbauen

   Bob fügt dem Deploy-Skript eine einzige Zeile hinzu. Sie sieht aus wie harmlose Build-Telemetrie, schickt aber jede Umgebungsvariable an einen Server, den er kontrolliert. Das Deploy-Skript läuft in der CI des Projekts, und dort gehören zu diesen Variablen Deploy-Keys und Registry-Token. Eine Zeile, in einer Datei, die der Pull Request mit keinem Wort erwähnt. Das ist der ganze Angriff.

5. Unauffällig platziert

   Die Zeile könnte von einer Person aus dem Build-Team stammen und steht zwischen gewöhnlichen Deployment-Schritten. Sie wirkt nicht sofort verdächtig — bei einer flüchtigen Prüfung kann sie deshalb durchrutschen.

6. Beide Änderungen committen

   Bob merkt beide Änderungen für denselben Commit vor: die echte Testkorrektur und die Zeile im Deploy-Skript. So tarnt die nützliche Änderung die bösartige.

7. Auf den Fork pushen

   Bob pusht den Branch in seinen Fork. Der Push landet in seiner eigenen Kopie des Repositorys, und die Plattform antwortet mit einem Link, über den er einen Pull Request gegen Fennroot eröffnen kann.

8. Den Pull Request eröffnen

   Bob eröffnet einen Pull Request im Fennroot-Repository. Titel und Beschreibung erwähnen nur den instabilen Test, nicht aber das Deploy-Skript. Der Reviewer soll die Testkorrektur sehen und die Backdoor übersehen.

9. Auf den Merge drängen

   Nachdem der Pull Request eröffnet ist, fügt Bob einen freundlichen Kommentar hinzu, der auf einen schnellen Merge drängt. Er platziert ihn an der Testzeile, damit der Blick des Reviewers dorthin und nicht auf das Deploy-Skript fällt. So erhöht er den sozialen Druck, schnell zuzustimmen, bevor jemand genau hinsieht.

10. Wissenscheck