Czy „LD_LIBRARY_PATH” stanowi zagrożenie bezpieczeństwa?

Wiemy, że ld.sowyszukiwania bibliotek w katalogach określonych przez zmienną środowiskową $LD_LIBRARY_PATH, ale zwykli użytkownicy mogą uruchomić:

export LD_LIBRARY_PATH=dir1:dir2...

Mogą zapisywać zainfekowaną bibliotekę w ścieżce o wyższym priorytecie niż oryginalna, dzięki czemu ld.soznajdzie ją zamiast zaufanej biblioteki w ld.so.cache.

Czy to ryzyko?
Jak możemy wyłączyć zapisywanie do tej zmiennej środowiskowej dla zwykłego użytkownika?

W ogóle nie stanowi to zagrożenia dla bezpieczeństwa, ponieważ zawsze można ustawić zmienne środowiskowe dla bieżącego środowiska (np. Bieżącej sesji Bash) i, używając exportpolecenia, jego środowisk potomnych (uruchamiane skrypty, podpowłoki itp.). Nie można eskalować zmiennej środowiskowej utworzonej lub zmodyfikowanej w środowisku nadrzędnym. Obejmuje to, że zwykli użytkownicy nie mogą oczywiście dokonywać zmian w całym systemie.

Tak więc jedynym środowiskiem, na które ucierpiałoby uruchomienie, export LD_LIBRARY_PATH=...jest twoja bieżąca powłoka i wszelkie jej podpowłoki, które możesz później odrodzić. Załóżmy, że zmieniłeś ścieżkę wyszukiwania, tak aby zawierała zainfekowane biblioteki na początku, tj. O najwyższym priorytecie. Następnie uruchom plik wykonywalny, który ładuje jedną z zainfekowanych bibliotek lib, nawet nie wiedząc. Co się teraz stanie?

Szkodliwy kod (z zainfekowanej biblioteki) działa na Twoim koncie użytkownika z regularnymi uprawnieniami nieadministracyjnymi. Może to zabrzmieć źle, ale w rzeczywistości ... więc co z tego? Działa z zwykłymi uprawnieniami użytkownika, co oznacza, że ​​nie może wpływać na cały system. Nawiasem mówiąc, bezpośrednie uruchomienie pliku wykonywalnego z tym samym złośliwym kodem byłoby znacznie łatwiejsze niż zmodyfikowanie ścieżki wyszukiwania biblioteki i oczekiwanie na załadowanie normalnego pliku wykonywalnego.

Wniosek: zwykły użytkownik może jedynie modyfikować własną ścieżkę wyszukiwania bibliotek, co oznacza, że ​​może również ładować te biblioteki na konto zwykłego użytkownika z regularnymi uprawnieniami niesystemowymi. To powiedziawszy, nie ma znaczenia, czy wymuszają ładowanie zainfekowanej biblioteki, czy bezpośrednio uruchamiają zainfekowany plik wykonywalny. Nie zyskałbyś absolutnie nic, gdyby ta zmienna środowiskowa nie mogła zostać zastąpiona przez użytkowników.

PS: Istnieją również pliki wykonywalne, które mają ustawioną flagę setuid lub setgid , co oznacza, że ​​nie będą działać jako użytkownik / grupa tego, który je uruchamia, ale tego, który jest ich właścicielem . Na przykład sudoplik wykonywalny jest własnością root i ma ustawioną flagę setuid , co oznacza, że ​​zawsze działa jako root po uruchomieniu. Ze względów bezpieczeństwa $LD_LIBRARY_PATHzmienna jest ignorowana przez pliki wykonywalne z ustawioną jedną z flag setuid / setgid, aby mieć pewność, że zwykły użytkownik nie będzie mógł uruchomić pliku wykonywalnego z uprawnieniami administratora do ładowania dowolnych bibliotek.
_{(Dzięki @Rinzwind za zwrócenie na to uwagi!)}