Onlangs werd bekendgemaakt dat er een kritieke kwetsbaarheid is ontdekt in de pakketrepository RubyGems.org (de kwetsbaarheid is al gecatalogiseerd onder CVE-2022-29176). Deze kwetsbaarheid maakt het mogelijk om , zonder de juiste autorisatie, pakketten van anderen in de repository te vervangen door een legitiem pakket te verwijderen (yank) en in plaats daarvan een ander bestand met dezelfde naam en versie te uploaden.
Er wordt vermeld dat de kwetsbaarheid te wijten is aan een bug in de "yank"-actiehandler , die het deel van de naam na het koppelteken als de platformnaam beschouwt, waardoor het mogelijk is om het verwijderen van externe pakketten te initiëren die overeenkomen in het deel van de naam tot aan het koppelteken.
In het bijzonder werd in de code van de handler voor de "yank"-bewerking de aanroep 'find_by!(full_name: "#{rubygem.name}-#{slug}")' gebruikt om naar pakketten te zoeken, terwijl de parameter "slug" werd doorgegeven aan de eigenaar van het pakket om de te verwijderen versie te bepalen.
De eigenaar van het "rails-html"-pakket had "sanitizer-1.2.3" kunnen specificeren in plaats van de "1.2.3"-versie, waardoor de bewerking van toepassing zou zijn op de "rails-html-sanitizer-1.2.3" pakket ″ van iemand anders. »
Gisteren werd een beveiligingsadvies voor Rubygems.org gepubliceerd.
Het advies betrof een bug waardoor een kwaadwillende gebruiker bepaalde edelstenen kon delven en verschillende bestanden met dezelfde naam, versienummer en ander platform kon uploaden.
Laten we eens dieper kijken om te zien wat er mis is gegaan tijdens het extractieproces. Laten we ons als voorwendsel een scenario voorstellen waarin we een juweel genaamd "rails-html" maken met de bedoeling om ongeautoriseerde toegang te krijgen tot het veelgebruikte "rails-html-sanitizer"-juweel.
Er wordt vermeld dat er aan drie voorwaarden moet worden voldaan om deze kwetsbaarheid succesvol te kunnen exploiteren:
- De aanval kan alleen worden uitgevoerd op pakketten met een koppelteken in hun naam.
- Een aanvaller moet een edelsteenpakket kunnen plaatsen met een deel van de naam tot aan het koppelteken. Als de aanval bijvoorbeeld gericht is tegen het pakket "rails-html-sanitizer", moet de aanvaller zijn eigen pakket "rails-html" in de repository plaatsen.
- Het aangevallen pakket moet in de afgelopen 30 dagen zijn gemaakt of 100 dagen niet zijn bijgewerkt.
Het probleem werd ontdekt door een beveiligingsonderzoeker in het kader van het HackerOne-bountyprogramma, dat gericht is op het opsporen van beveiligingslekken in bekende open-sourceprojecten.
Het probleem is op 5 mei verholpen op RubyGems.org en volgens de ontwikkelaars hebben ze de afgelopen 18 maanden geen sporen van misbruik van de kwetsbaarheid in de logbestanden gevonden. Er is echter tot nu toe slechts een oppervlakkige audit uitgevoerd en een meer diepgaande audit staat gepland voor de toekomst.
Op dit moment zijn we van mening dat er geen misbruik is gemaakt van deze kwetsbaarheid.
RubyGems.org stuurt een e-mail naar alle eigenaren van edelstenen wanneer een edelsteenversie wordt vrijgegeven of verwijderd. We hebben geen support-e-mails ontvangen van eigenaren van edelstenen waarin staat dat hun edelsteen zonder toestemming is gedolven.
Een controle van de veranderingen van edelstenen in de afgelopen 18 maanden vond geen voorbeelden van kwaadwillig gebruik van dit beveiligingslek. Verdere controle op mogelijk gebruik van deze exploit heeft in de geschiedenis van RubyGems geen enkel geval gevonden waarin deze exploit werd gebruikt om een ​​edelsteen over te nemen zonder toestemming. We kunnen niet garanderen dat het nooit is gebeurd, maar het lijkt niet waarschijnlijk.
Om uw projecten te verifiëren, is het raadzaam om de geschiedenis van bewerkingen in het Gemfile.lock-bestand te analyseren. Kwaadaardige activiteit wordt uitgedrukt in de aanwezigheid van wijzigingen met dezelfde naam en versie, of een platformwijziging (bijvoorbeeld wanneer een pakket xxx-1.2.3 1.2.3 is bijgewerkt naar xxx-XNUMX-xxx).
Om te voorkomen dat verborgen pakketten worden geïmpliceerd in continue integratiesystemen of bij het publiceren van projecten, wordt ontwikkelaars aangeraden Bundler te gebruiken met de opties "--frozen" of "--deployment" om afhankelijkheden te controleren.
Als u hier meer over wilt weten , kunt u de details vinden via de volgende link.