Nyligen bröt nyheten ut det En kritisk sårbarhet identifierades i paketförrådet rubygems.org (sårbarheten är redan katalogiserad under CVE-2022-29176), vilket tillåta utan vederbörligt tillstånd, ersätta andras paket i förvaret genom att dra ett legitimt paket och ladda upp en annan fil med samma namn och versionsnummer i stället.
Det nämns det sårbarheten beror på en bugg i "yank"-handlingshanteraren, som behandlar delen av namnet efter bindestrecket som plattformsnamnet, vilket gjorde det möjligt att initiera borttagning av externa paket som matchar den del av namnet upp till bindestrecket.
I synnerhet i kontrollkoden för operationen "rycka", uppropet 'find_by!(full_name: "#{rubygem.name}-#{slug}")' användes för att söka efter paket, medan parametern "slug" skickades till paketägaren för att fastställa vilken version som skulle tas bort.
Ägaren till "rails-html"-paketet kunde ha angett "sanitizer-1.2.3" istället för "1.2.3"-versionen, vilket skulle göra att operationen tillämpas på "rails-html-sanitizer-1.2.3" paket ″ från någon annan. »
En säkerhetsrådgivning för Rubygems.org publicerades i går.
Rådgivningen gällde en bugg som gjorde det möjligt för en illvillig användare att bryta vissa ädelstenar och ladda upp olika filer med samma namn, versionsnummer och annan plattform.
Låt oss ta en djupare titt för att se vad som gick fel när vi gick igenom extraktionsprocessen. Som förevändning, låt oss föreställa oss ett scenario där vi skapar en pärla som kallas "rails-html" med avsikten att få obehörig tillgång till den mycket använda "rails-html-sanitizer" pärlan.
Det nämns det tre villkor måste vara uppfyllda, för att framgångsrikt utnyttja denna sårbarhet:
- Attacken kan endast utföras på paket som har ett bindestreck i sitt namn.
- En angripare ska kunna placera ett ädelstenspaket med en del av namnet upp till bindestrecket. Till exempel, om attacken är mot "rails-html-sanitizer"-paketet, måste angriparen lägga sitt eget "rails-html"-paket i förvaret.
- Det attackerade paketet måste ha skapats under de senaste 30 dagarna eller inte uppdaterats på 100 dagar.
Problemet identifierades av en säkerhetsforskare som en del av HackerOne bounty-programmet för att hitta säkerhetsproblem i kända öppen källkodsprojekt.
Problemet fixad på RubyGems.org den 5 maj och enligt utvecklarna, har ännu inte identifierat spår av exploatering av sårbarheten i loggarna under de senaste 18 månaderna. Samtidigt har endast en ytlig revision genomförts hittills och en mer djupgående revision planeras i framtiden.
För närvarande tror vi att denna sårbarhet inte har utnyttjats.
RubyGems.org skickar ett e-postmeddelande till alla ädelstensägare när en ädelstensversion släpps eller tas bort. Vi har inte fått några supportmejl från ädelstensägare som indikerar att deras ädelsten har utvunnits utan tillstånd.
En granskning av ädelstensförändringar under de senaste 18 månaderna fann inga exempel på skadlig användning av denna sårbarhet. Ytterligare granskning för eventuell användning av denna exploatering fann inga exempel på att denna exploit användes för att ta över en pärla utan tillstånd i RubyGems historia. Vi kan inte garantera att det aldrig har hänt, men det verkar inte troligt.
För att verifiera dina projekt rekommenderas det att analysera operationshistoriken i Gemfile.lock-filen Skadlig aktivitet uttrycks i närvaro av ändringar med samma namn och version, eller en plattformsändring (till exempel när ett paket xxx-1.2.3 1.2.3 uppdateras till xxx-XNUMX-xxx).
Som en lösning mot spoofing av dolda paket i kontinuerliga integrationssystem eller vid publicering av projekt, Utvecklare rekommenderas att använda Bundler med alternativen "–fryst" eller "–distribution" för att bekräfta beroenden.
Slutligen, om du är intresserad av att veta mer om detkan du kontrollera detaljerna i följande länk.