Ruby łata błędy Onigmo powiązane z krytycznymi lukami RCE w GitLab - Security Bez Tabu

Ruby łata błędy Onigmo powiązane z krytycznymi lukami RCE w GitLab

Cybersecurity news

Wprowadzenie do problemu / definicja

Ekosystem Ruby otrzymał poprawki usuwające trzy błędy w Onigmo, czyli silniku wyrażeń regularnych wbudowanym w język. Problem ma istotne znaczenie dla bezpieczeństwa, ponieważ podatności nie ograniczają się do jednego produktu. W określonych scenariuszach aplikacja może kompilować wyrażenia regularne utworzone z danych kontrolowanych przez atakującego, co otwiera drogę do uszkodzenia pamięci i potencjalnie do zdalnego wykonania kodu.

W skrócie

Ruby opublikował wersje 4.0.9, 3.4.12 oraz 3.3.13 w celu usunięcia trzech błędów w Onigmo. Luki zostały powiązane z krytycznymi podatnościami, które wcześniej załatał GitLab. Kluczowy problem dotyczy kompilacji wzorców regex pochodzących z niezaufanego wejścia, a nie samego używania statycznych wyrażeń regularnych przygotowanych przez programistów.

  • Poprawki dotyczą silnika regex Onigmo w Ruby.
  • Ryzyko pojawia się przy dynamicznym tworzeniu wzorców z danych użytkownika.
  • Skutkiem może być korupcja pamięci i potencjalne RCE.
  • Gałąź Ruby 3.2 i starsze nie otrzymają już aktualizacji bezpieczeństwa w tym zakresie.

Kontekst / historia

Impulsem do nagłośnienia problemu były wcześniejsze działania GitLab, który publikował poprawki dla kolejnych krytycznych błędów związanych z obsługą regexów. Według dostępnych informacji specjalnie przygotowany wzorzec mógł prowadzić do uszkodzenia pamięci już na etapie kompilacji wyrażenia regularnego, a więc jeszcze przed faktycznym dopasowywaniem tekstu.

Szczególne znaczenie ma to, że GitLab wykorzystuje mechanizmy umożliwiające przetwarzanie wzorców dostarczanych przez użytkowników, między innymi w konfiguracjach CI/CD. To właśnie taki model użycia pokazał, że zagrożenie nie ma wyłącznie charakteru teoretycznego. Część wcześniejszych luk wymagała posiadania konta, natomiast kolejne scenariusze były oceniane jako poważniejsze ze względu na niższy próg wykorzystania.

Dodatkowym utrudnieniem dla zespołów bezpieczeństwa jest brak bezpośrednich identyfikatorów CVE przypisanych początkowo po stronie samego interpretera Ruby. W praktyce mogło to ograniczać widoczność ryzyka w organizacjach opierających procesy wykrywania podatności na automatycznym mapowaniu numerów CVE.

Analiza techniczna

Technicznie problem dotyczy Onigmo, silnika obsługującego wyrażenia regularne w Ruby. Błędy ujawniają się wtedy, gdy aplikacja kompiluje regex z ciągu znaków pochodzącego od użytkownika lub z innego niezaufanego źródła. Dotyczy to między innymi mechanizmów tworzenia obiektu regex z tekstu wejściowego, łączenia wzorców oraz interpolacji danych do wzorca.

Najważniejsze jest rozróżnienie między dopasowywaniem a kompilacją. W tym przypadku podatność nie wynika z samego porównywania tekstu z gotowym wzorcem, ale z etapu kompilacji złośliwie spreparowanego regexu. Taki wzorzec może prowadzić do błędów zarządzania pamięcią, a więc do scenariuszy groźniejszych niż klasyczny ReDoS.

Podatne mogą być zwłaszcza aplikacje, które dynamicznie budują wyrażenia regularne na podstawie danych wejściowych i następnie przekazują je do interpretera bez odpowiednich ograniczeń architektonicznych.

  • przyjmowanie wzorców regex bezpośrednio od użytkowników,
  • generowanie regexów na podstawie parametrów wejściowych,
  • interpolowanie danych użytkownika do literałów regex,
  • używanie kompilacji regexów w modułach walidacji, filtrowania lub automatyzacji.

Warto podkreślić, że proste środki ograniczające nie rozwiązują całego problemu. Ustawienie limitów czasu dla wykonywania regexów nie eliminuje błędów występujących na etapie kompilacji, a samo ograniczanie długości wzorca nie daje gwarancji bezpieczeństwa. Nawet relatywnie krótkie ciągi mogą wyzwolić niepożądane zachowanie parsera i kompilatora.

Wersje naprawcze wskazywane dla użytkowników to Ruby 4.0.9, 3.4.12 oraz 3.3.13. Istotne jest również to, że wydanie 4.0.8 nie zawierało pełnego zestawu poprawek, a gałąź Ruby 3.2 i starsze pozostają poza zakresem nowych aktualizacji bezpieczeństwa.

Konsekwencje / ryzyko

Ryzyko biznesowe i techniczne jest wysokie tam, gdzie użytkownik może pośrednio wpływać na definicję wyrażeń regularnych. Dotyczy to platform DevOps, systemów reguł, parserów konfiguracji, bramek walidacyjnych oraz usług wielodostępnych przetwarzających treści od użytkowników.

  • możliwość zdalnego wykonania kodu w określonych scenariuszach,
  • uszkodzenie pamięci procesu aplikacji,
  • utrudnione wykrywanie ekspozycji przez narzędzia zależne od CVE,
  • podwyższone ryzyko dla systemów publicznie dostępnych,
  • potencjalny wpływ na łańcuch CI/CD i mechanizmy automatyzacji.

Dla administratorów GitLab szczególnie ważne jest wdrożenie wersji produktu zawierających poprawiony runtime Ruby. W środowiskach self-managed sama świadomość problemu po stronie języka nie wystarcza, ponieważ poprawka musi zostać zastosowana również na poziomie końcowego produktu i jego zintegrowanych komponentów.

Rekomendacje

Organizacje korzystające z Ruby powinny w pierwszej kolejności zidentyfikować miejsca, w których aplikacja tworzy wyrażenia regularne z niezaufanych danych. Szczególnej kontroli wymagają moduły walidacji, wyszukiwania, interpretacji konfiguracji i automatyzacji.

  • zaktualizować Ruby do wersji 4.0.9, 3.4.12 lub 3.3.13, zależnie od używanej gałęzi,
  • w przypadku GitLab wdrożyć wersje produktu zawierające poprawiony runtime Ruby,
  • wyeliminować dynamiczną kompilację regexów z danych wejściowych użytkownika,
  • zastąpić interpolację wzorców podejściem opartym na predefiniowanych, bezpiecznych szablonach,
  • przeprowadzić przegląd kodu pod kątem użycia mechanizmów kompilujących regex,
  • rozszerzyć monitoring o logi i reguły detekcyjne związane z próbami dostarczania nietypowych wzorców,
  • uwzględnić ten scenariusz w testach bezpieczeństwa aplikacyjnego oraz modelowaniu zagrożeń,
  • zaplanować migrację z niewspieranych wersji Ruby, jeśli środowisko nadal z nich korzysta.

W środowiskach produkcyjnych warto również ograniczyć zaufanie do danych wejściowych i odseparować funkcje interpretujące złożone wzorce od krytycznych komponentów przetwarzających żądania. Tam, gdzie pełna eliminacja dynamicznych regexów nie jest możliwa, rozsądne będzie dodatkowe izolowanie procesów oraz minimalizacja uprawnień usług.

Podsumowanie

Najnowsze poprawki Ruby pokazują, że wyrażenia regularne pozostają obszarem realnego ryzyka, szczególnie wtedy, gdy aplikacja traktuje dane użytkownika jako materiał do budowy wzorca. W tym przypadku zagrożenie wykracza poza klasyczny ReDoS i obejmuje błędy pamięci mogące prowadzić do RCE. Dla zespołów bezpieczeństwa kluczowe są szybka aktualizacja środowisk Ruby i GitLab, przegląd kodu odpowiedzialnego za dynamiczne regexy oraz korekta procesów oceny ekspozycji.

Źródła

  1. Ruby Fixes Three Regex Engine Bugs Responsible for Four Critical GitLab RCE Flaws