Kürzlich wurde bekannt gegeben, dass eine kritische Sicherheitslücke im RubyGems.org -Paket-Repository entdeckt wurde (die Sicherheitslücke ist bereits unter CVE-2022-29176 katalogisiert), die es ermöglicht , ohne entsprechende Autorisierung die Pakete anderer Personen im Repository zu ersetzen, indem ein legitimes Paket entfernt (Yank) und stattdessen eine andere Datei mit demselben Namen und derselben Versionsnummer hochgeladen wird.
Es wird darauf hingewiesen, dass die Sicherheitslücke auf einen Fehler im „yank“-Aktionshandler zurückzuführen ist , der den Teil des Namens nach dem Bindestrich als Plattformnamen interpretiert. Dadurch ist es möglich, die Entfernung externer Pakete zu initiieren, deren Name bis zum Bindestrich übereinstimmt.
Insbesondere wurde im Code des Handlers für die Operation "yank" der Aufruf 'find_by!(full_name: "#{rubygem.name}-#{slug}")' verwendet, um nach Paketen zu suchen, während der Parameter "slug" an den Paketbesitzer übergeben wurde, um die zu entfernende Version zu bestimmen.
Der Eigentümer des Pakets „rails-html“ hätte „sanitizer-1.2.3“ anstelle der Version „1.2.3“ angeben können, was dazu führen würde, dass die Operation auf „rails-html-sanitizer-1.2.3“ angewendet wird. Paket ″ von jemand anderem. »
Gestern wurde ein Sicherheitshinweis für Rubygems.org veröffentlicht.
Die Empfehlung betraf einen Fehler, der es einem böswilligen Benutzer ermöglichte, bestimmte Juwelen zu schürfen und verschiedene Dateien mit demselben Namen, derselben Versionsnummer und unterschiedlicher Plattform hochzuladen.
Werfen wir einen genaueren Blick darauf, was beim Extrahieren schief gelaufen ist. Stellen wir uns als Vorwand ein Szenario vor, in dem wir ein Gem namens „rails-html“ mit der Absicht erstellen, unbefugten Zugriff auf das weit verbreitete Gem „rails-html-sanitizer“ zu erhalten.
Es wird darauf hingewiesen, dass drei Bedingungen erfüllt sein müssen , um diese Sicherheitslücke erfolgreich auszunutzen:
- Der Angriff kann nur auf Pakete ausgeführt werden, deren Name einen Bindestrich enthält.
- Ein Angreifer sollte in der Lage sein, eine Edelsteinpackung mit einem Teil des Namens bis zum Bindestrich zu platzieren. Wenn sich der Angriff beispielsweise gegen das Paket „rails-html-sanitizer“ richtet, muss der Angreifer sein eigenes Paket „rails-html“ in das Repository stellen.
- Das angegriffene Paket muss in den letzten 30 Tagen erstellt oder seit 100 Tagen nicht aktualisiert worden sein.
Das Problem wurde von einem Sicherheitsforscher im Rahmen des Bounty-Programms von HackerOne identifiziert, das darauf abzielt, Sicherheitslücken in bekannten Open-Source-Projekten aufzudecken.
Das Problem wurde am 5. Mai auf RubyGems.org behoben . Laut den Entwicklern wurden in den Protokollen der letzten 18 Monate keine Hinweise auf eine Ausnutzung der Sicherheitslücke gefunden. Bislang wurde jedoch nur eine oberflächliche Prüfung durchgeführt; eine detailliertere Untersuchung ist geplant.
Derzeit gehen wir davon aus, dass diese Schwachstelle nicht ausgenutzt wurde.
RubyGems.org sendet eine E-Mail an alle Gem-Besitzer, wenn eine Gem-Version veröffentlicht oder entfernt wird. Wir haben keine Support-E-Mails von Edelsteinbesitzern erhalten, die darauf hinweisen, dass ihr Edelstein ohne Genehmigung abgebaut wurde.
Eine Prüfung der Gem-Änderungen in den letzten 18 Monaten hat keine Beispiele für eine böswillige Nutzung dieser Schwachstelle gefunden. Eine weitere Prüfung auf eine mögliche Verwendung dieses Exploits ergab in der Geschichte von RubyGems keinen Fall, in dem dieser Exploit dazu verwendet wurde, ein Juwel ohne Genehmigung zu übernehmen. Wir können nicht garantieren, dass es nie passiert ist, aber es scheint nicht wahrscheinlich.
Um Ihre Projekte zu überprüfen, wird empfohlen, den Verlauf der Vorgänge in der Datei Gemfile.lock zu analysieren. Böswillige Aktivitäten äußern sich in Anwesenheit von Änderungen mit demselben Namen und derselben Version oder einer Plattformänderung (z. B. wenn ein Paket xxx-1.2.3 .1.2.3 wird auf xxx-XNUMX-xxx aktualisiert).
Als Lösung gegen die Nachahmung versteckter Pakete in Continuous-Integration-Systemen oder beim Veröffentlichen von Projekten wird Entwicklern empfohlen, Bundler mit den Optionen "--frozen" oder "--deployment" zu verwenden , um Abhängigkeiten zu bestätigen.
Wenn Sie schließlich mehr darüber erfahren möchten , finden Sie die Details unter folgendem Link.