Luka w RubyGems.org umożliwiająca fałszowanie pakietów innych osób

W repozytorium pakietów RubyGems.org wykryto krytyczną lukę (CVE-2022-29176), która umożliwia bez odpowiednich uprawnień zastąpienie pakietów innych osób w repozytorium poprzez zainicjowanie szarpnięcia legalnego pakietu i załadowanie go w jego miejsce inny plik o tej samej nazwie i numerze wersji.

Aby pomyślnie wykorzystać tę lukę, muszą zostać spełnione trzy warunki:

  • Atak może zostać przeprowadzony wyłącznie na pakietach, które mają w nazwie łącznik.
  • Osoba atakująca musi być w stanie umieścić paczkę z klejnotami zawierającą część nazwy przed znakiem łącznika. Na przykład, jeśli atak dotyczy pakietu „rails-html-sanitizer”, osoba atakująca musi umieścić w repozytorium swój własny pakiet „rails-html”.
  • Atakowany pakiet musiał zostać utworzony w ciągu ostatnich 30 dni lub nie być aktualizowany przez 100 dni.

Podatność spowodowana jest błędem w procedurze obsługi akcji „yank”, która interpretuje część nazwy po myślniku jako nazwę platformy, co umożliwiło zainicjowanie usuwania obcych pakietów pasujących do części nazwy przed łącznikiem. W szczególności w kodzie obsługi „yank” do znalezienia pakietów użyto wywołania „find_by!(full_name: „#{rubygem.name}-#{slug}”)”, natomiast parametr „slug” został przekazany przez właściciela pakietu, aby określić wersję do usunięcia. Właściciel pakietu „rails-html” mógłby określić „sanitizer-1.2.3” zamiast wersji „1.2.3”, co spowodowałoby wykonanie operacji na cudzym pakiecie „rails-html-sanitizer-1.2.3 „.

Problem został zidentyfikowany przez badacza bezpieczeństwa w ramach programu nagród HackerOne za znajdowanie problemów związanych z bezpieczeństwem w znanych projektach typu open source. Problem został naprawiony w RubyGems.org 5 maja i według twórców nie zidentyfikowali jeszcze w logach żadnych śladów wykorzystania luki w ciągu ostatnich 18 miesięcy. Jednocześnie dotychczas przeprowadzono jedynie powierzchowny audyt, w przyszłości planowany jest audyt bardziej szczegółowy.

Aby sprawdzić swoje projekty, zaleca się analizę historii operacji w pliku Gemfile.lock; złośliwa aktywność wyraża się w obecności zmian z zachowaniem nazwy i wersji lub zmianą platformy (np. gdy gemname Pakiet -1.2.3 został zaktualizowany do gemname-1.2.3-java). Jako obejście zabezpieczające przed ukrytym zastępowaniem pakietów w systemach ciągłej integracji lub podczas publikowania projektów, programistom zaleca się używanie Bundlera z opcjami „-frozen” lub „-deployment” w celu naprawienia zależności.

Źródło: opennet.ru

Dodaj komentarz