Google enthüllt eine Sicherheitslücke bei GitHub

Project Zero hat Details zu einer schwerwiegenden Sicherheitsverletzung auf GitHub veröffentlicht und sie berichten das Der Fehler wirkt sich auf Aktionsworkflow-Befehle aus von GitHub und wird als hoher Schweregrad beschrieben. (Dieser Fehler wurde im Juli entdeckt, aber basierend auf der Standard-Offenlegungsfrist von 90 Tagen wurden die Details erst jetzt veröffentlicht.)

Dieser Fehler wurde zu einer der wenigen Sicherheitslücken, die nicht behoben wurden ordnungsgemäß, bevor der von Google Project Zero gewährte Standardzeitraum von 90 Tagen abgelaufen ist.

Laut Felix Wilhelm (wer hat es entdeckt), das Mitglied des Project Zero-Teams, der Fehler wirkt sich auf die Aktionsfunktion von GitHub aus, einem Tool zur Automatisierung der Arbeit von Entwicklern. Dies liegt daran, dass Aktionen-Workflow-Befehle "anfällig für Injektionsangriffe" sind:

„Aktionen Github unterstützt eine Funktion namens Workflow-Befehle als Kommunikationskanal zwischen dem Aktionsbroker und der ausgeführten Aktion. Workflow-Befehle sind in / src / Runner.Worker / ActionCommandManager.cs implementiert und analysieren STDOUT aller Aktionen, die ausgeführt werden, indem nach einer der beiden Befehlsmarkierungen gesucht wird.

Erwähne das Das große Problem bei dieser Funktion ist, dass sie sehr anfällig für Injektionsangriffe ist. Da der Ausführungsprozess jede in STDOUT gedruckte Zeile nach Workflow-Befehlen durchsucht, ist jede GitHub-Aktion, die im Rahmen ihrer Ausführung nicht vertrauenswürdigen Inhalt enthält, anfällig.

In den meisten Fällen führt die Möglichkeit, beliebige Umgebungsvariablen festzulegen, zur Ausführung von Remotecode, sobald ein anderer Workflow ausgeführt wird. Ich habe einige Zeit damit verbracht, mir beliebte GitHub-Repositorys anzuschauen, und fast jedes Projekt, das leicht komplexe GitHub-Aktionen verwendet, ist für diese Art von Fehler anfällig.

Anschließend gab einige Beispiele, wie der Fehler ausgenutzt werden könnte und schlug auch eine Lösung vor:

„Ich bin mir wirklich nicht sicher, wie ich das am besten beheben kann. Ich denke, die Art und Weise, wie die Workflow-Befehle implementiert werden, ist grundsätzlich unsicher. Das Abwerten der v1-Befehlssyntax und das Verstärken vonet-env mit einer Zulassungsliste würde wahrscheinlich gegen direkte RCE-Vektoren funktionieren.

„Selbst die Möglichkeit, die in späteren Schritten verwendeten 'normalen' Umgebungsvariablen zu überschreiben, reicht wahrscheinlich aus, um die komplexeren Aktionen auszunutzen. Ich habe auch nicht die Sicherheitsauswirkungen der anderen Steuerelemente im Arbeitsbereich analysiert.

außerdemErwähnen Sie, dass eine gute langfristige Lösung Es wäre, die Workflow-Befehle in einen separaten Kanal (z. B. einen neuen Dateideskriptor) zu verschieben, um ein Parsen durch STDOUT zu vermeiden. Dadurch wird jedoch ein Großteil des vorhandenen Aktionscodes beschädigt.

Was GitHub betrifft, so haben seine Entwickler am 1. Oktober einen Hinweis veröffentlicht und die anfälligen Befehle abgelehnt. Wilhelm stellte jedoch fest, dass es sich tatsächlich um eine "moderate Sicherheitsanfälligkeit" handelt. GitHub hat die Fehlerkennung CVE-2020-15228 zugewiesen:

„In der Laufzeit von GitHub Actions wurde eine moderate Sicherheitslücke festgestellt, die möglicherweise das Einfügen von Pfaden und Umgebungsvariablen in Workflows ermöglicht, die nicht vertrauenswürdige Daten in STDOUT protokollieren. Dies kann ohne Einführung des Workflow-Autors zur Einführung oder Änderung von Umgebungsvariablen führen.

„Um dieses Problem zu lösen und Umgebungsvariablen dynamisch festlegen zu können, haben wir einen neuen Satz von Dateien eingeführt, mit denen Umgebungs- und Pfadaktualisierungen in Workflows verarbeitet werden können.

„Wenn Sie selbst gehostete Broker verwenden, stellen Sie sicher, dass diese auf Version 2.273.1 oder höher aktualisiert sind.

Laut Wilhelm hat Project Zero am 12. Oktober GitHub kontaktiert und ihnen proaktiv ein 14-Tage-Fenster angeboten, wenn GitHub mehr Zeit zum Deaktivieren der anfälligen Befehle haben möchte. Natürlich wurde das Angebot angenommen und GitHub hoffte, die anfälligen Befehle nach dem 19. Oktober deaktivieren zu können. Project Zero legte dann den neuen Veröffentlichungstermin für den 2. November fest.

Quelle: https://bugs.chromium.org


Hinterlasse einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert mit *

*

*

  1. Verantwortlich für die Daten: Miguel Ángel Gatón
  2. Zweck der Daten: Kontrolle von SPAM, Kommentarverwaltung.
  3. Legitimation: Ihre Zustimmung
  4. Übermittlung der Daten: Die Daten werden nur durch gesetzliche Verpflichtung an Dritte weitergegeben.
  5. Datenspeicherung: Von Occentus Networks (EU) gehostete Datenbank
  6. Rechte: Sie können Ihre Informationen jederzeit einschränken, wiederherstellen und löschen.