For nylig brød nyheden det En kritisk sårbarhed blev identificeret i pakkelageret rubygems.org (sårbarheden er allerede katalogiseret under CVE-2022-29176), hvilket tillade uden behørig tilladelse, erstatte andres pakker i depotet ved at trække en legitim pakke og uploade en anden fil med samme navn og versionsnummer i stedet for.
Det nævnes det sårbarheden skyldes en fejl i "yank" handlingshåndteringen, som behandler den del af navnet efter bindestregen som platformnavnet, hvilket gjorde det muligt at igangsætte fjernelse af eksterne pakker, der matcher den del af navnet op til bindestregen.
Især i controllerkoden for operationen "ryst", kaldes 'find_by!(fuldt_navn: "#{rubygem.name}-#{slug}")' blev brugt til at søge efter pakker, mens parameteren "slug" blev videregivet til pakkeejeren for at bestemme, hvilken version der skulle fjernes.
Ejeren af "rails-html"-pakken kunne have angivet "sanitizer-1.2.3" i stedet for "1.2.3"-versionen, hvilket ville få handlingen til at gælde for "rails-html-sanitizer-1.2.3" pakke ″ fra en anden. »
En sikkerhedsadvisering for Rubygems.org blev offentliggjort i går.
Rådgivningen vedrørte en fejl, der gjorde det muligt for en ondsindet bruger at mine visse ædelstene og uploade forskellige filer med samme navn, versionsnummer og anden platform.
Lad os tage et dybere kig for at se, hvad der gik galt, mens vi gik gennem udvindingsprocessen. Som et påskud, lad os forestille os et scenarie, hvor vi skaber en perle kaldet "rails-html" med den hensigt at få uautoriseret adgang til den meget brugte "rails-html-sanitizer" perle.
Det nævnes det tre betingelser skal være opfyldt, for at kunne udnytte denne sårbarhed:
- Angrebet kan kun udføres på pakker, der har en bindestreg i deres navn.
- En angriber bør være i stand til at placere en ædelstenspakke med en del af navnet op til bindestregen. For eksempel, hvis angrebet er mod "rails-html-sanitizer"-pakken, skal angriberen lægge deres egen "rails-html"-pakke i depotet.
- Den angrebne pakke skal være oprettet inden for de sidste 30 dage eller ikke opdateret i 100 dage.
Problemet blev identificeret af en sikkerhedsforsker som en del af HackerOne bounty-programmet for at finde sikkerhedsproblemer i kendte open source-projekter.
Problemet fast på RubyGems.org den 5. maj og ifølge udviklerne, har endnu ikke identificeret spor efter udnyttelse af sårbarheden i logfilerne for de sidste 18 måneder. Samtidig er der indtil videre kun gennemført en overfladisk revision, og der er planlagt en mere dybdegående revision i fremtiden.
På nuværende tidspunkt mener vi, at denne sårbarhed ikke er blevet udnyttet.
RubyGems.org sender en e-mail til alle ædelstensejere, når en ædelstensversion frigives eller fjernes. Vi har ikke modtaget nogen support-e-mails fra ædelstensejere, der indikerer, at deres ædelsten er blevet udvundet uden tilladelse.
En revision af ædelstensændringer i løbet af de seneste 18 måneder fandt ingen eksempler på ondsindet brug af denne sårbarhed. Yderligere revision for enhver mulig brug af denne udnyttelse fandt ingen tilfælde af, at denne udnyttelse blev brugt til at overtage en perle uden tilladelse i RubyGems' historie. Vi kan ikke garantere, at det aldrig er sket, men det virker ikke sandsynligt.
For at verificere dine projekter anbefales det at analysere historikken for operationer i Gemfile.lock-filen Ondsindet aktivitet kommer til udtryk i tilstedeværelsen af ændringer med samme navn og version, eller en platformsændring (f.eks. når en pakke xxx-1.2.3 1.2.3 er opdateret til xxx-XNUMX-xxx).
Som en løsning mod spoofing af skjulte pakker i kontinuerlige integrationssystemer eller ved publicering af projekter, Udviklere anbefales at bruge Bundler med indstillingerne "–frozen" eller "–deployment" for at bekræfte afhængigheder.
Endelig hvis du er interesseret i at vide mere om det, kan du kontrollere detaljerne i følgende link.