Nylig brøt nyheten det En kritisk sårbarhet ble identifisert i pakkelageret rubygems.org (sårbarheten er allerede katalogisert under CVE-2022-29176), som tillater uten riktig autorisasjon, erstatte andres pakker i depotet ved å dra en legitim pakke og laste opp en annen fil med samme navn og versjonsnummer i stedet.
Det er nevnt at sårbarheten skyldes en feil i "yank"-handlingsbehandleren, som behandler delen av navnet etter bindestreken som plattformnavnet, noe som gjorde det mulig å sette i gang fjerning av eksterne pakker som matcher delen av navnet opp til bindestrek.
Spesielt i kontrollerkoden for operasjonen "rykke", oppfordringen 'find_by!(full_name: "#{rubygem.name}-#{slug}")' ble brukt til å søke etter pakker, mens "slug"-parameteren ble sendt til pakkeeieren for å bestemme hvilken versjon som skulle fjernes.
Eieren av "rails-html"-pakken kunne ha spesifisert "sanitizer-1.2.3" i stedet for "1.2.3"-versjonen, noe som ville føre til at operasjonen gjelder for "rails-html-sanitizer-1.2.3" pakke ″ fra noen andre. »
Et sikkerhetsråd for Rubygems.org ble publisert i går.
Rådgivningen gjaldt en feil som tillot en ondsinnet bruker å utvinne visse edelstener og laste opp forskjellige filer med samme navn, versjonsnummer og annen plattform.
La oss ta en dypere titt for å se hva som gikk galt mens vi gikk gjennom utvinningsprosessen. Som et påskudd, la oss forestille oss et scenario der vi lager en perle kalt "rails-html" med den hensikt å få uautorisert tilgang til den mye brukte "rails-html-sanitizer"-perlen.
Det er nevnt at tre vilkår må være oppfylt, for å kunne utnytte dette sikkerhetsproblemet:
- Angrepet kan bare utføres på pakker som har en bindestrek i navnet.
- En angriper skal kunne plassere en edelstenspakke med deler av navnet opp til bindestrek. For eksempel, hvis angrepet er mot "rails-html-sanitizer"-pakken, må angriperen legge sin egen "rails-html"-pakke i depotet.
- Den angrepne pakken må ha blitt opprettet i løpet av de siste 30 dagene eller ikke oppdatert på 100 dager.
Problemet ble identifisert av en sikkerhetsforsker som en del av HackerOne bounty-programmet for å finne sikkerhetsproblemer i kjente åpen kildekode-prosjekter.
Problemet fast på RubyGems.org 5. mai og ifølge utviklerne, har ennå ikke identifisert spor etter utnyttelse av sårbarheten i loggene de siste 18 månedene. Samtidig er det så langt kun gjennomført en overfladisk revisjon, og det planlegges en mer dyptgående revisjon i fremtiden.
For øyeblikket mener vi at denne sårbarheten ikke har blitt utnyttet.
RubyGems.org sender en e-post til alle edelstenseiere når en edelstensversjon er utgitt eller fjernet. Vi har ikke mottatt noen støtte-e-poster fra edelstenseiere som indikerer at edelstenen deres har blitt utvunnet uten autorisasjon.
En revisjon av edelstensendringer de siste 18 månedene fant ingen eksempler på ondsinnet bruk av dette sikkerhetsproblemet. Ytterligere revisjon for eventuell bruk av denne utnyttelsen fant ingen tilfeller av at denne utnyttelsen ble brukt til å overta en perle uten autorisasjon i RubyGems historie. Vi kan ikke garantere at det aldri har skjedd, men det virker ikke sannsynlig.
For å verifisere prosjektene dine, anbefales det å analysere operasjonshistorikken i Gemfile.lock-filen Skadelig aktivitet kommer til uttrykk i nærvær av endringer med samme navn og versjon, eller en plattformendring (for eksempel når en pakke xxx-1.2.3 1.2.3 er oppdatert til xxx-XNUMX-xxx).
Som en løsning mot spoofing av skjulte pakker i kontinuerlige integrasjonssystemer eller ved publisering av prosjekter, Utviklere anbefales å bruke Bundler med alternativene «–frozen» eller «–deployment» for å bekrefte avhengigheter.
Endelig, hvis du er interessert i å vite mer om det, kan du sjekke detaljene i følgende lenke.