luka "GerriScary" w Gerrit ujawniła ryzyko integralności kodu w kluczowych projektach Google

Niedawno ujawniona luka w Gerrit, otwartoźródłowym systemie przeglądu kodu używanym m.in. przez Google, mogła ujawnić ścieżkę umożliwiającą wprowadzenie nieautoryzowanego kodu do krytycznych projektów oprogramowania bez standardowych procesów zatwierdzania. Badacze bezpieczeństwa z Tenable ujawnili, że usterka wynikała z błędnie skonfigurowanych uprawnień i logiki etykiet recenzji. W niektórych konfiguracjach atakujący mogli wykorzystać funkcję znaną jako "addPatchSet" do modyfikowania już zatwierdzonych zmian, potencjalnie wprowadzając złośliwy kod bez uruchamiania ponownego przeglądu.

Oddzielny raport sporządzony przez CybersecurityAsia.net potwierdził, że atakujący mogli ominąć etapy ręcznej weryfikacji i użyć zautomatyzowanych narzędzi do wstawienia nieautoryzowanego kodu bez interakcji użytkownika.

Co najmniej 18 głośnych repozytoriów zostało zidentyfikowanych jako podatne na ataki, w tym projekty związane z Chromium, Dart, Bazel i innymi komponentami infrastruktury. Problem dotyczył również warunku wyścigu w automatycznym procesie przesyłania, umożliwiając atakującym działanie w krótkim oknie przed scaleniem kodu.

W momencie ujawnienia informacji nie zaobserwowano żadnego potwierdzonego wykorzystania tej luki na wolności. Firma Tenable przeprowadziła odpowiedzialne testy przy użyciu łagodnego kodu i nie próbowała w pełni wykorzystać luki.

Od tego czasu Google wdrożyło zmiany w konfiguracji w celu złagodzenia problemu. W międzyczasie Tenable ostrzegło, że inne projekty open source korzystające z Gerrita powinny przejrzeć swoje konfiguracje, ponieważ podobne ustawienia mogą istnieć gdzie indziej, i zaleca wszystkim użytkownikom Gerrita audyt reguł uprawnień i zasad trwałości etykiet w celu zapewnienia integralności kodu. Błędne konfiguracje mogą mieć również wpływ na inne organizacje korzystające z Gerrit, szczególnie tam, gdzie obowiązują domyślne ustawienia uprawnień i zautomatyzowane procesy przesyłania kodu. Incydent ten podkreśla ciągłe znaczenie bezpiecznych środowisk programistycznych w ekosystemie open source.