In de RubyGems.org-pakketrepository is een kritieke kwetsbaarheid (CVE-2022-29176) ontdekt, die het mogelijk maakt om sommige externe pakketten in het repository te vervangen zonder de juiste bevoegdheden door een legitiem pakket te laten intrekken (yank) en in plaats daarvan een ander bestand met dezelfde naam en versie te uploaden.
Voor een succesvolle exploitatie van de kwetsbaarheid zijn drie voorwaarden nodig:
- De aanval kan alleen worden uitgevoerd op pakketten waarvan de naam een koppelteken bevat.
- De aanvaller moet in staat zijn om een gem-pakket te plaatsen met een deel van de naam vóór het koppelteken. Bijvoorbeeld, als de aanval gericht is op het pakket ‘rails-html-sanitizer’, moet de aanvaller zijn eigen pakket ‘rails-html’ in het repository plaatsen.
- Het pakket waarop de aanval wordt uitgevoerd, moet in de afgelopen 30 dagen zijn aangemaakt of in de afgelopen 100 dagen niet zijn bijgewerkt.
De kwetsbaarheid is veroorzaakt door een fout in de handler voor de actie ‘yank’, die het deel van de naam na het koppelteken interpreteert als de naam van een platform, wat het mogelijk maakte om het verwijderen van externe pakketten die overeenkomen in het deel van de naam vóór het koppelteken te starten. In het bijzonder werd in de code van de ‘yank’-operatie de ‘find_by! (full_name: ‘#{rubygem.name}-#{slug}’)’-aanroep gebruikt om pakketten te vinden, terwijl de parameter ‘slug’ door de pakketbeheerder werd doorgegeven om de te verwijderen versie te bepalen. De eigenaar van het pakket ‘rails-html’ kon in plaats van versie ‘1.2.3’ ‘sanitizer-1.2.3’ opgeven, wat zou leiden tot de uitvoering van de operatie op het externe pakket ‘rails-html-sanitizer-1.2.3’.
Het probleem is ontdekt door een beveiligingsonderzoeker binnen het huidige HackerOne-programma voor het uitkeren van beloningen voor het vinden van beveiligingsproblemen in bekende open source-projecten. Het probleem is op 5 mei opgelost in RubyGems.org en volgens de ontwikkelaars zijn er tot nu toe geen tekenen van exploitatie van de kwetsbaarheid gevonden in de logs van de afgelopen 18 maanden. Tot nu toe is er echter slechts een oppervlakkige audit uitgevoerd en er zijn plannen voor een diepgaandere inspectie.
Voor het controleren van uw projecten is het aan te raden om de geschiedenis van bewerkingen in het bestand Gemfile.lock te analyseren. Kwaadaardige activiteiten uiten zich in wijzigingen waarbij de naam en versie behouden blijven of waarbij het platform verandert (bijvoorbeeld, wanneer het pakket gemname-1.2.3 wordt geüpdatet naar gemname-1.2.3-java). Als een omweg om verborgen vervangingen van pakketten in continue integratiesystemen of bij het publiceren van projecten te voorkomen, wordt ontwikkelaars aanbevolen Bundler te gebruiken met de opties "—frozen" of "—deployment" om afhankelijkheden vast te leggen.
Bron: opennet.ru
