Podczas czytania tego znalazłem następujący exploit:
% cp /usr/bin/id ~
% chmod -x ~/id
% ls -al ~/id
-rw-r--r-- 1 edd edd 22020 2012-08-01 15:06 /home/edd/id
% ~/id
zsh: permission denied: /home/edd/id
% /lib/ld-linux.so.2 ~/id
uid=1001(edd) gid=1001(edd) groups=1001(edd),1002(wheel)
Ten fragment pokazuje, że możemy w trywialny sposób ominąć uprawnienia systemu plików do wykonywania jako normalny nieuprzywilejowany użytkownik. Uruchomiłem to na Ubuntu 12.04.
Podczas gdy moduł ładujący Linux jest obiektem współdzielonym zgodnie z plikiem (1), ma również punkt wejścia, który pozwala na jego bezpośrednie wykonanie. Po wykonaniu w ten sposób moduł ładujący systemu Linux działa jako interpreter dla plików binarnych ELF.
Jednak na moim komputerze OpenBSD ten exploit nie jest skuteczny, ponieważ nie możesz uruchomić programu ładującego jako programu. Strona podręcznika OpenBSD mówi: „Sam ld.so jest współdzielonym obiektem, który jest początkowo ładowany przez jądro.”.
Wypróbuj to na Solaris 9, a otrzymasz awarię. Nie jestem pewien, co dzieje się gdzie indziej.
Moje pytania są zatem:
- Dlaczego moduł ładujący systemu Linux (gdy jest wykonywany bezpośrednio) nie sprawdza atrybutów systemu plików przed interpretacją pliku binarnego ELF?
- Po co wdrażać mechanizm, który ma uniemożliwiać wykonywanie plików, jeśli jest tak trywialnie odsunięty? Czy coś przeoczyłem?
źródło
libc
(raz zrobiłem, uaktualniając Arch Archa), będziesz wdzięczny za to małe dziwactwo.Odpowiedzi:
Celem
execute
pozwolenia nie jest ogólne zapobieganie wykonaniu . Jest to (1), aby powiedzieć progamom, które pliki mają zostać wykonane, i (2), aby zapobiec wykonaniu jako użytkownik uprzywilejowany , gdy określony jest bit setuid (itp.).Włamanie do linkera jest mniej ryzykowne niż się wydaje. Możesz wykonać dowolny plik wykonywalny, do którego odczytu masz uprawnienia, jeszcze łatwiej:
Zobacz tę dyskusję na forum Arch Linux .
W podsumowaniu:
Oznaczanie plików, które należy wykonać
Kiedy piszesz skrypt powłoki, możesz oznaczyć go jako wykonywalny przy pomocy
chmod +x
. Wskazuje to twojej powłoce, że zamierzasz być wykonywalny (w przeciwnym razie dla całej powłoki to tylko kolejny plik tekstowy). Powłoka może następnie wyświetlać ją w tabulatorze podczas pisania./
Tab.Podobnie:
something.d
katalogi (np.init.d
) Zawierają skrypty powłoki startowej lub kontrolnej, które są zwykle wykonywane automatycznie przez demony. Możesz umieścić plik komentarza lub plik README w katalogu jako zwykły plik tekstowy. Lub możesz tymczasowo wyłączyć jeden ze skryptów. Możesz to zrobić, usuwając bit wykonania dla tego konkretnego pliku. Mówi to demonowi, aby go pominął.Zapobieganie uprzywilejowanemu wykonaniu
Do
setuid
bit oznacza, że podczas wykonywania pliku, jest on wykonywany jako określonego użytkownika (na przykład root).Wpis na forum dobrze to wyjaśnia:
źródło
Jeśli masz dostęp do odczytu pliku, zawsze możesz wykonać jego kopię.
Jeśli możesz wykonać kopię osobistą, zawsze możesz zaznaczyć tę kopię jako wykonywalną.
To nie wyjaśnia zachowania ld-linuxa, ale wskazuje, że może nie być to bardzo przydatna luka bezpieczeństwa.
Jeśli chcesz ściślejszego bezpieczeństwa, rozważ SELinux
źródło
Patrząc na pytanie nieco inaczej: jak mówi Mechanical Snail, uprawnienie do wykonywania pliku nie ma na celu uniemożliwienia wykonania. Jednak opcja systemu plików „noexec” uniemożliwia wykonanie i nie jest tak łatwo ominięta (nie obsługiwana przez wszystkie systemy plików, ale z pewnością przez najpopularniejsze systemy Linux). Jeśli administrator chciałby uniemożliwić użytkownikom uruchamianie własnych programów, może określić opcję noexec w katalogach domowych i tmp oraz w innych, w których użytkownicy mogą tworzyć pliki.
Najwyraźniej można było obejść opcję noexec przy użyciu sztuczki ładującej wspomnianej w pytaniu, ale zostało to naprawione w jądrze kilka wersji wstecz.
Z http://linux.die.net/man/8/mount :
źródło