In dem Paket-Repository RubyGems.org wurde eine kritische Sicherheitslücke (CVE-2022-29176) entdeckt, die es ohne die erforderlichen Berechtigungen ermöglicht, einige fremde Pakete im Repository durch das Initiieren einer Rücknahme (yank) eines legitimen Pakets zu ersetzen und stattdessen eine andere Datei mit demselben Namen und Versionsnummer hochzuladen.
Für die erfolgreiche Ausnutzung der Sicherheitslücke müssen drei Bedingungen erfüllt sein:
- Der Angriff kann nur auf Pakete durchgeführt werden, deren Name ein Bindestrich enthält.
- Der Angreifer muss in der Lage sein, ein gem-Paket mit einem Teil des Namens vor dem Bindestrich zu erstellen. Zum Beispiel, wenn der Angriff auf das Paket „rails-html-sanitizer“ gerichtet ist, muss der Angreifer sein eigenes Paket „rails-html“ im Repository bereitstellen.
- Das Zielpaket, das angegriffen wird, muss innerhalb der letzten 30 Tage erstellt worden sein oder darf in den letzten 100 Tagen nicht aktualisiert worden sein.
Die Schwachstelle wird durch einen Fehler im Aktionshandler „yank“ verursacht, der einen Teil des Namens nach dem Bindestrich als Plattformnamen interpretiert. Dies ermöglichte die Initiierung der Löschung von fremden Paketen, deren Namen bis zum Bindestrich übereinstimmten. Insbesondere wurde im Code des „yank“-Operationhandlers zur Paketfindung der Aufruf ‘find_by!(full_name: «#{rubygem.name}-#{slug}»)‘ verwendet, wobei der Parameter „slug“ vom Paketinhaber übergeben wurde, um die zu löschende Version zu bestimmen. Der Eigentümer des Pakets „rails-html“ konnte anstelle der Version „1.2.3“ „sanitizer-1.2.3“ angeben, was dazu geführt hätte, dass die Operation auf das fremde Paket „rails-html-sanitizer-1.2.3“ angewendet wurde.
Das Problem wurde von einem Sicherheitsforscher im Rahmen des aktuellen HackerOne-Belohnungsprogramms zur Identifizierung von Sicherheitsproblemen in bekannten Open-Source-Projekten entdeckt. Das Problem wurde am 5. Mai in RubyGems.org behoben, und den Angaben der Entwickler zufolge wurden in den letzten 18 Monaten keine Anzeichen für eine Ausnutzung der Schwachstelle in den Protokollen gefunden. Bei der Überprüfung wurde bisher nur eine oberflächliche Prüfung durchgeführt, und es ist geplant, eine tiefere Überprüfung durchzuführen.
Um Ihre Projekte zu überprüfen, empfiehlt es sich, die Änderungsverlaufshistorie in der Datei Gemfile.lock zu analysieren. Schadhafte Aktivitäten äußern sich durch Änderungen, die entweder den Namen und die Version beibehalten oder die Plattform wechseln (z. B. wenn das Paket gemname-1.2.3 auf gemname-1.2.3-java aktualisiert wird). Als Umgehungsmaßnahme zum Schutz vor versteckten Paketänderungen in Continuous-Integration-Systemen oder bei der Veröffentlichung von Projekten wird den Entwicklern empfohlen, Bundler mit den Optionen „—frozen“ oder „—deployment“ zu verwenden, um Abhängigkeiten zu fixieren.
Quelle: opennet.ru
