{"id":103981,"date":"2022-05-09T09:36:45","date_gmt":"2022-05-09T07:36:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-rubygems-org-pozvolyayushhaya-podmenit-chuzhie-pakety"},"modified":"2022-05-09T09:36:45","modified_gmt":"2022-05-09T07:36:45","slug":"uyazvimost-v-rubygems-org-pozvolyayushhaya-podmenit-chuzhie-pakety","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/uyazvimost-v-rubygems-org-pozvolyayushhaya-podmenit-chuzhie-pakety","title":{"rendered":"Schutzl\u00fccke in RubyGems.org, die den Austausch fremder Pakete erm\u00f6glicht","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Im RubyGems.org-Paket-Repository wurde eine kritische Sicherheitsanf\u00e4lligkeit (CVE-2022-29176) entdeckt, die es erm\u00f6glicht, ohne die erforderlichen Berechtigungen einige fremde Pakete im Repository zu ersetzen, indem ein legitimes Paket zur\u00fcckgezogen (yank) und stattdessen eine andere Datei mit demselben Namen und derselben Versionsnummer hochgeladen wird. <\/p>\n
F\u00fcr eine erfolgreiche Ausnutzung der Schwachstelle m\u00fcssen drei Bedingungen erf\u00fcllt sein: <\/p>\n
\n
Angriffe k\u00f6nnen nur auf Pakete durchgef\u00fchrt werden, deren Name ein Minuszeichen enth\u00e4lt.\n
Ein Angreifer sollte die M\u00f6glichkeit haben, ein Gem-Paket mit einem Teil des Namens vor dem Bindestrich zu platzieren. Wenn zum Beispiel ein Angriff auf das Paket \u201erails-html-sanitizer\u201c ausgef\u00fchrt wird, sollte der Angreifer sein eigenes Paket \u201erails-html\u201c im Repository platzieren.\n
Das Paket, auf das der Angriff abzielt, muss in den letzten 30 Tagen erstellt worden sein oder darf in den letzten 100 Tagen nicht aktualisiert worden sein. <\/ul>\n
Die Schwachstelle entsteht durch einen Fehler im Aktionshandler \u201eyank\u201c, der den Teil des Namens nach dem Bindestrich als Plattformnamen interpretiert, was es erm\u00f6glichte, das L\u00f6schen von fremden Paketen einzuleiten, deren Name vor dem Bindestrich \u00fcbereinstimmte. Insbesondere wurde im Code des \u201eyank\u201c-Operationhandlers der Aufruf \u201efind_by!(full_name: \u201e#{rubygem.name}-#{slug}\u201c)\u201c genutzt, wobei der Parameter \u201eslug\u201c vom Paketinhaber \u00fcbergeben wurde, um die zu l\u00f6schende Version zu bestimmen. Der Eigent\u00fcmer des Pakets \u201erails-html\u201c konnte anstelle der Version \u201e1.2.3\u201c \u201esanitizer-1.2.3\u201c angeben, was dazu f\u00fchren w\u00fcrde, dass die Operation auf das fremde Paket \u201erails-html-sanitizer-1.2.3\u201c angewendet wurde. <\/p>\n
Das Problem wurde von einem Sicherheitsforscher im Rahmen des Programms zur Belohnung f\u00fcr die Auffindung von Sicherheitsproblemen in bekannten Open-Source-Projekten auf HackerOne identifiziert. Das Problem wurde am 5. Mai in RubyGems.org behoben, und laut den Entwicklern wurden in den letzten 18 Monaten keine Spuren der Ausnutzung der Schwachstelle in den Protokollen gefunden. Bisher wurde nur eine oberfl\u00e4chliche Pr\u00fcfung durchgef\u00fchrt, und es ist geplant, eine ausf\u00fchrlichere Untersuchung durchzuf\u00fchren. <\/p>\n
Um ihre Projekte zu \u00fcberpr\u00fcfen, wird empfohlen, die Historie der Operationen in der Datei Gemfile.lock zu analysieren. B\u00f6swillige Aktivit\u00e4ten \u00e4u\u00dfern sich in der Anwesenheit von \u00c4nderungen mit beibehaltenem Namen und Version oder einem Wechsel der Plattform (zum Beispiel, wenn das Paket gemname-1.2.3 auf gemname-1.2.3-java aktualisiert wurde). Als Umgehungsmethode zum Schutz gegen versteckte Manipulationen von Paketen in kontinuierlichen Integrationssystemen oder bei der Ver\u00f6ffentlichung von Projekten wird Entwicklern empfohlen, Bundler mit den Optionen \u201e--frozen\u201c oder \u201e--deployment\u201c zur Fixierung von Abh\u00e4ngigkeiten zu verwenden. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"