Wpływ
LibreNMS w wersji 24.9.1 i wcześniejszych zawiera lukę, która umożliwia uwierzytelnionym użytkownikom wykonanie wstrzyknięcia polecenia systemu operacyjnego [S2]. Pomyślna eksploatacja umożliwia wykonanie dowolnych poleceń z uprawnieniami użytkownika serwera WWW [S1]. Może to prowadzić do pełnego naruszenia bezpieczeństwa systemu, nieautoryzowanego dostępu do wrażliwych danych monitorowania i potencjalnego ruchu poprzecznego w infrastrukturze sieci zarządzanej przez LibreNMS [S2].
Główna przyczyna
Przyczyną luki jest niewłaściwa neutralizacja danych wejściowych dostarczonych przez użytkownika przed ich włączeniem do polecenia systemu operacyjnego [S1]. Wada ta klasyfikowana jest jako CWE-78 [S1]. W wersjach, których dotyczy problem, określone uwierzytelnione punkty końcowe nie sprawdzają prawidłowości ani nie oczyszczają parametrów przed przekazaniem ich do funkcji wykonawczych na poziomie systemu [S2].
Naprawa
Użytkownicy powinni zaktualizować swoją instalację LibreNMS do wersji 24.10.0 lub nowszej, aby rozwiązać ten problem [S2]. Zgodnie z ogólną najlepszą praktyką w zakresie bezpieczeństwa dostęp do interfejsu administracyjnego LibreNMS powinien być ograniczony do zaufanych segmentów sieci przy użyciu zapór sieciowych lub list kontroli dostępu (ACL) [S1].
Jak FixVibe to testuje
FixVibe uwzględnia to teraz w skanach repozytorium GitHub. Kontrola odczytuje tylko pliki zależności autoryzowanego repozytorium, w tym composer.lock i composer.json. Oznacza librenms/librenms zablokowane wersje lub ograniczenia pasujące do zakresu, którego dotyczy problem, <=24.9.1, a następnie zgłasza plik zależności, numer linii, identyfikatory doradcze, zakres, którego dotyczy problem i poprawioną wersję.
Jest to statyczna kontrola repo przeznaczona tylko do odczytu. Nie wykonuje kodu klienta i nie wysyła ładunków exploitów.