Ładowarka dynamiczna , zawarty w OpenBSD, może, pod pewnymi warunkami, - aplikacje pozostawiają zmienną środowiskową LD_LIBRARY_PATH, umożliwiając w ten sposób załadowanie kodu strony trzeciej w kontekście procesu działającego z podwyższonymi uprawnieniami. W kolejnych wersjach dostępne są łatki naprawiające lukę и . Łaty binarne () dla platform amd64, i386 i arm64 są już w fazie produkcji i powinny być dostępne do pobrania do czasu opublikowania tej wiadomości.
Istota problemu: ld.so w trakcie działania najpierw pobiera ze środowiska wartość zmiennej LD_LIBRARY_PATH i przy pomocy funkcji _dl_split_path() zamienia ją na tablicę stringów - ścieżek do katalogów. Jeśli później okaże się, że bieżący proces jest uruchamiany przez aplikację SUID/SGID, wówczas utworzona tablica, a właściwie zmienna LD_LIBRARY_PATH zostaną wyczyszczone. Jednocześnie, jeśli w _dl_split_path() zabraknie pamięci (co jest trudne ze względu na jawne ograniczenie wielkości zmiennych środowiskowych do 256 kB, ale teoretycznie możliwe), wówczas zmienna _dl_libpath otrzyma wartość NULL, a kolejne sprawdzenia wartość tej zmiennej wymusi pominięcie wywołania _dl_unsetenv("LD_LIBRARY_PATH").
Luka znaleziona przez ekspertów , jak również problemy. Badacze bezpieczeństwa, którzy zidentyfikowali tę lukę, zauważyli, jak szybko problem został rozwiązany: przygotowano łatkę i wydano aktualizacje w ciągu trzech godzin od otrzymania powiadomienia przez projekt OpenBSD.
Dodatek: Problemowi został przypisany numer . Dokonano na liście mailingowej oss-security , w tym prototypowy exploit działający na architekturach OpenBSD 6.6, 6.5, 6.2 i 6.1
amd64 i i386 (exploit można dostosować do innych architektur).
Problem można wykorzystać w domyślnej instalacji i umożliwia nieuprzywilejowanemu użytkownikowi lokalnemu wykonanie kodu jako root poprzez podstawienie biblioteki podczas uruchamiania narzędzi suid chpass lub passwd. Aby stworzyć warunki małej ilości pamięci niezbędne do działania, ustaw limit RLIMIT_DATA za pomocą setrlimit.
Źródło: opennet.ru